it-swarm.cn

您实际上写的是“干净的代码”吗?

我已经看到一些程序员一遍又一遍地调整他们的代码,不仅使它“运行良好”,而且使它“看上去良好”。

IMO,“干净代码”实际上是对您代码的优雅,完美理解和可维护性的一种称赞。而且,当您必须在美观的代码和难以看清的代码之间进行选择时,就会出现区别。

那么,你们当中有多少人实际编写了“干净的代码”?这是一个好习惯吗?这样做的其他好处或缺点是什么?

57
ykombinator

我会说我们中的许多人不会编写干净的代码。通常,不是我们的工作。作为软件开发人员,我们的工作是按时交付有效的产品。

我想起了Joel Spolsky的博客文章: 管道胶带编程器

他引用了 工作中的编码员

最终,运送f ***** g东西!很好地重写代码并使代码更整洁,到第三次它实际上会变得很漂亮。但这不是重点–您不是在这里编写代码;您在这里运送产品。 -杰米·扎温斯基

我也想起了 Robert Martin的博客回复

所以。放聪明点。要干净很简单船!准备好一小卷胶带,不要害怕使用它。 -鲍伯叔叔

如果开发人员编写的代码恰好干净而且可以正常工作(可以交付),那么对所有人都有利。但是,如果开发人员不停地尝试制作清晰易读的代码,却以能够及时交付代码为代价,那就不好了。使它工作,使用胶带将其运输。您可以稍后对其进行重构,使其变得超级华丽和高效。

是的,写干净的代码是个好习惯,但绝不以牺牲交付能力为代价。准时交付带有导管的产品的好处远远超过了从未完成和交付的干净代码的好处。

我遇到的很多代码都不干净。有些非常丑陋。但是它们都已发布并用于生产。有人可能会说编写混乱的代码是不专业的。我不同意。专业的工作是交付有效的代码,无论它是干净的还是杂乱的。给定交付前分配的时间,开发人员必须尽其所能。然后,回去清理-专业。希望提供的代码不是纯胶带,而且“足够干净”。

54
spong

您必须确保您的代码具有很好的可读性,整洁性和可维护性。那就是所有程序员必须所做的事情。

但是您在谈论over styling(比起girl-code这个术语更好),它只不过是作者的自我。

我曾经看到许多开发人员为自己的创造感到骄傲(就像在洗手间一样;),他们花费了数小时来清理和完善代码。其中一些非常细致,以至于确保尊重成员之间的正确空白。

太多了

我发现这种行为适得其反。在专业上下文中,您必须是专业。通过编写干净,可读性强和可维护的代码,并与快乐的用户或同事交谈,您可以使您满意。

39
user2567

我不同意这个问题的答案。

您的责任显然是要发货,但是通常您也有责任发货自己和未来的开发人员可以尽可能经济有效地维护的产品。

我曾在现场担任过糟糕的维护程序员或顾问,他们不得不了解和调试一些庞大的未记录系统,并且我可以告诉您,糟糕的设计和混乱的代码可能会导致数小时甚至数天的浪费。我可以想到很多情况,最初的开发人员多付出N个小时的努力就可以节省5N的时间。

我知道这方面有一个统计数据,但是根据我在多个项目中的经验,在扩展和维护期间,每行编写的代码被读取5至20次。

因此,我想说将代码清理到其寿命的一英寸之内。这需要时间,但可能会在项目的整个生命周期内节省净成本。

24
Benjamin Wootton

如果我们知道在引擎盖下进行故障排除,维护或修理非常麻烦并且难以进行,并且需要花费更多的资源来运行,那么我们中的任何人都会买车吗?

为什么一件软件会有什么不同?

仅仅因为最终用户看不到内幕,并不意味着他们永远不会知道。迟早会出现。

回答问题“您实际上编写'干净的代码'吗?” - 哦耶。!

21
Sifar

如果使用“干净代码”,您是说我会尽力确保代码尽可能清晰吗?

哎呀。

代码越干净,代码越清晰,维护起来就越容易,从长远来看,可以节省您的时间。不要将干净的代码视为虚荣。将其视为一项投资,以节省未来的精力和时间。

18
GrandmasterB

老实说,这取决于。我喜欢每个人都大声疾呼:“除了干净的文档之外,任何事情都是荒唐的事情!”,但是我在一个部署周期很短且零监督的企业中工作:我会尽我所能,但是我写很多代码,很难写出其他人都能写的干净完美的代码claims

我尝试编写可以由具有大致能力的人轻松维护的代码。我评论棘手的部分,命名程序,变量和类的友好名称,进行部署,然后继续。我没有时间做其他事情。

有时我对此感到内,但不是很内。您应该看到我每天都会处理的一些恐怖事件。数十种模糊语言的自定义代码,零文档。我的一位同事专门在Visual Basic 6.0中进行开发,并在各处部署了以秘密方式命名的二进制文件。我替换的女人专门在 [〜#〜] rpg [〜#〜] 中编程。

我很难相信,就像我当程序员的那几年所看到的那样可怕的废话,Everyone仅生成干净的代码。

15
Satanicpuppy

我认为我不喜欢“女孩代码”一词,但干净的代码=可维护的代码。什么都不是专业的。

作为一般规则,我考虑下一位不得不看我一团糟的开发人员。

很多时候是我...几个月后...当我不记得它是如何工作的...而我进行更改的时间却更少了。

7
Heath Lilley

我尝试用鲍勃·马丁(Bob Martin)的感觉写“干净的代码”(例如OO设计)。在编写干净的代码时有great值。它更易于维护。

然后,我让ReSharper为我设置“漂亮的代码”(例如对齐,换行等)。编写漂亮的代码时有good值。但是回报却在减少。由于易于阅读,有些修饰使其更易于维护。

如果您认为整齐地排列巨大的代码块以使其具有可读性是必要的,那么问题就在于您的freakin巨大的代码块!这个太大了。我看到许多例子,说明人们非常努力地美化一些设计很差的代码。

如果我没有ReSharper,我仍然会拥有干净的代码,但它不会那么漂亮。

我认为我花在美化上面的时间不会超过5%。这意味着我的编辑器越强大,越熟练,就可以做得越漂亮。

5
dss539

似乎没有人提出符合您公司最大利益的观点吗?

通常,程序员(如果不是总是这样)只是雇员,尽管管理决策可能使我们感到沮丧,但我们常常没有他们所做的所有数据。

例如,假设该公司签订了一项条款,规定如果该软件未及时准备就绪,您将不会获得付款(这只是发生在我们身上,尽管我认为我们毕竟已经付款了)。是的,干净的代码很重要,但更重要的是要在付款日之前使代码正常工作!

另一个例子-公司财务状况不佳,需要筹集一些资金。猜猜谁在乎质量?您可以稍后对其进行修复,如果需要的话,就可以发货!

一个参数可能是“为什么我应该卖光并编写糟糕的代码?”。那么,为什么您的公司每月都要向您支付一张尼斯支票?选择,我的朋友。如果您追求理想主义,请尝试 自由软件基金会 ;我听说他们在做一些很酷的事情(我的意思是,我尊重FSF和OSS)。

另一方面,如果您在一个预期使用量会爆炸性增长的项目上工作(尽管这样的预测几乎永远都不是准确的),那么您最好为所需的最佳代码质量打下坚实的基础,因为这几乎可以肯定会维护是项目的更大成本。

程序员喜欢“干净”的代码,无论这意味着什么。我们甚至无法就干净的东西达成共识,但我们喜欢它。但是,有时它与可用性和正确性无关紧要。这些看起来似乎是同义词,但并非如此-如果您在4个小时内就看到一个真正的Perl黑客编写的代码,意图被使用两次并扔掉,那么您会意识到它不是干净的,但是可以。

所以有时候,除了自我,我们应该让它工作。请注意,我不建议编写不良代码作为习惯。我只是指出这可能是必要的。 完善可能需要您的公司花费一些时间。因此,如果您的雇主不介意,可以制作软件,但如果需要,只需编写工作代码,不用介意“清洁”。 这不是一个``一刀切''的答案-您应该优先考虑。

4
K.Steff

太多的事情永远都没有好处。

但是,“不干净”的代码要记住的重要一点是,它很容易导致“ 破损的窗户 ”。如果代码的格式很差,我认为许多新手可能会不太愿意做好维护和升级工作,从而导致螺旋式下降,最终可能会影响软件的工作状态。

因此,在代码中保持一定程度的整洁不仅对您的同伴开发者有所帮助。不要在上面花费太多时间(已经提到了5%)。了解如何使用自己的工具来自动执行手动任务(在这种情况下为代码格式)。对您所做的事情负责,并始终做对您的公司/客户/用户最有利的事情。

3
Per Noalt

这是鲍勃·马丁(Bob Martin)的“清洁代码”的一句话:

为了把这一点讲清楚,如果您是一名医生并且有一个病人因为您花费太多时间而要求您停止所有愚蠢的洗手以准备手术,该怎么办?显然,病人是老板。但是医生绝对应该拒绝遵守。为什么?因为医生比患者更了解疾病和感染的风险。医生遵从患者的要求是不专业的(不要介意犯罪)。

因此,程序员屈服于那些不了解制造混乱风险的经理的意愿也是不专业的。

3
Tulains Córdova

我不确定“看起来不错”和“优雅,完全可以理解和可维护”是否等效。

我尝试编写“优雅,完全可理解和可维护”的代码。我确实重构了自己的代码以更好地符合这些条件。

除了造成的时间成本外,我看不到任何弊端。

为了使代码“看起来不错”,有很多自动化工具,可以根据需要适当缩进和间隔所有内容。

3
back2dos

我喜欢代码易于阅读,但是最重要的是一致性。对我来说,这意味着要与命名约定保持一致and函数之间的间距,if语句的同一行或下一行的括号等。

当然,有时候有人用一致的代码样式编写某些东西,但仍然让我发疯。特别是不会“呼吸”的代码。例如:

void function1(){
    //whatever code
}
int fooBar(){
    //whatever else
}
Foo* someOtherFooBar(int value){
    if(value){
        //do something
    }
    return ...;
}

好吧……使用Objective-C方法看起来更糟,并且嵌套了很多if语句,并且行长于80个字符。但这仍然让我很烦:)

2
vedosity

我认为“干净的代码”应该比您以前在物理/工程/数学考试中写的代码更干净或更干净。如果太乱了,则平地机将不会理解您的工作,即使正确,也可能会将其标记为错误。

2
chiurox

我确实竭尽全力清理代码。我认为这可以极大地帮助Bug脱颖而出。

我不同意“立即运送他妈的东西”的概念,因为干净的代码是对未来的投资。另外,太多的软件附带了太多的错误。我认为解决一个错误比实现一项新功能要好。

另外,如果您看 程序员生产力估计值 ,我认为我的得分也不算太差。编写干净的代码是一种习惯,作为程序员的经验越多,使用它的效率就越高。如果一个人从不尝试,显然,它将永远不会获得经验。

要考虑的另一点是,大多数开发人员将时间用于阅读代码,因此可读代码大大减少了阅读时间。例如,了解未公开的算法可能会很昂贵,并且会引发新的错误。

我肯定会想念的一件事,就是希望有一天能自动适应我的风格,这确实可以为我节省一些时间,特别是在阅读其他人的代码时。

干净的编码确实有一个与完美主义的联系,这确实有可能永远不会实现,但是我认为这主要是在您入门时遇到的一个问题,因为您在以后进行投资以及在重用自己优雅的代码段时结合您的经验,随着年龄的增长,与杂乱的编码器相比,您将变得非常有生产力,并且不会被错误困扰。

这是一块 的代码演示了我的编码风格。

2
user20416

只是避免使用“虚荣代码”。那里有很多开发人员纯粹是出于虚荣(或由于OCD)所做的事情,而没有其他事情。我的内裤真的和那些人在一起。

1
ElGringoGrande

我写的代码试图以最有效和理论上“优雅”的方式解决给定的问题。从这个意义上讲,这是干净的。如果完成后碰巧是“漂亮”,那就这样吧。

我从有限的经验中发现,当人们抱怨“干净代码”时,丑陋通常是可怕的解决方案而不是编码约定的结果。

1
Kurtis

我会说我努力写出更简洁的代码,但是由于时间限制或如果我正在做一些困难的事情,这可能会改变。当专注于使其工作时,它往往变得凌乱。然后我回去整理一下。如果返回到代码,并且不得不花太多时间刷新内存,则注释不够。

干净的代码很好,但是像其他所有代码一样,它只需要足够干净即可。缩进5行代码4空格和1行5空格不会增加阅读难度。

1
JeffO

我认为这取决于您在做什么。如果我正在编写概念验证应用程序,那么我基本上是在牛仔编码我的屁股,而不回头。如果我正在开发实际上将要使用一段时间的应用程序,那么请确保我编写的代码足够好,并且一个月后就可以理解。

我认为样式化代码有点麻烦。如上文所述,您的工作是制造一种产品,而不是格式化代码,但我要说的是至少应该坚持一种定义的注释和编码风格。我不希望看到一半的骆驼变量和另一半的匈牙利语。

但是,这也取决于您所说的“干净代码”。

1
user7007

重构代码以使其美观大方,使其更易于阅读和维护。甚至很小的事情,例如对齐变量分配:

_int foo    = 1;
int bar    = 2;
int foobar = 3;
_

比起阅读更容易

_int foo = 1;
int bar = 2;
int foobar = 3;
_

这意味着以后进行调试时更容易浏览。

此外,在PHP中,您可以使用任意数量的随机代码块。我使用这些代码块对逻辑任务进行分组:

_// do x
{
    // ...
}

// do y
{
    // ...
}
_

这为相关代码添加了清晰的定义。

编辑:作为一项额外的奖励,如果您想暂时跳过某个逻辑代码块,可以轻松地在它们前面加上if (false)

0
Craige

我承认这样做;而且每次看到它的好处都不会被烦恼。我想它也更容易阅读,因此错误变得更加明显。但是真正的原因是我无法忍受难看的代码。

0
user281377