“清洁代码”实践真的那么清洁和有用吗？[关闭]

我目前在一家大公司实习，他们的软件交付结构正在发生许多变化（迁移到敏捷）。

在过去的几个月中，我注意到这种对Clean Code实践的宗教依恋，而这本书对于开发人员来说就像一本圣经。

现在，干净代码的最重要特征之一是自解释代码，它基于可理解的命名和严格的重构。这是no commenting规则。

我知道这段干净的代码是一项长期投资，可以减轻代码维护和改进的负担，但是...这真的值得大惊小怪吗？

任何人都可以分享他们在“清洁法规”方面的经验以及任何意见，无论我是太保守还是只是暂时的趋势。

programming-practices agile clean-code

— Arturs Vancans
source

许多好的问题会根据专家的经验产生一定程度的意见，但是对这个问题的答案往往几乎完全基于观点，而不是事实，参考文献或特定的专业知识。

— 蚊蚋

我对该书没有很高的评价（尽管它的作者）。通常，不要太教条。大多数编程建议是因为它们已被证明可以在实践中起作用，但是它们并不是绝对的真理，因此不必担心太多。继续阅读并按照您认为更正确的方法去做，但也不要重蹈覆辙。有可能比我们更聪明的人已经找到了比我们更好的解决方案。

— DPM

具有70个字符的名称的方法可能不仅仅要做一件事。违反SRP是吗？

— Tombatron

这是另一种想法，即从现在开始5或10年，当您是一家公司时可能不太关心干净代码的开发人员时，您将非常喜欢这种教条式的练习。

— Tombatron

我曾（简短地）在“没有评论”下工作，我非常希望它是一个有力的指导方针，而不是一条规则。有时需要注释-通常在模糊的业务逻辑中。名为的方法CalculateFoonicityMetric()可以准确地告诉您它在做什么，编写良好的代码将向您展示如何...但是这些都不能告诉您为什么。代码可以在显着什么（这乘用，通过其他的事情鸿沟，将其平方，加上该位......），但是在不清楚为什么（系数= A * B / C;广场上的帐户负FOO，调整漂移...）。我感谢您快速发表评论，解释原因。

— anaximander

Answers:

我知道这段干净的代码是一项长期投资，可以减轻代码维护和改进的负担，但是...这真的值得大惊小怪吗？

绝对。

重构非常重要，但是花费75％的时间来移动方法并花费大量的时间来确定其正确的标题似乎并不那么有效。

可以，但是请考虑，大公司可能要清除数年或数十年的错误代码。为此，将需要大量时间和精力。

要意识到的主要是，您俩都是对的。“清理代码”非常重要，清理代码是到达那里的普遍认可的方式。由于公司才刚刚起步，因此与拥有更多经验的团队相比，他们会更着迷于这本书。一旦完成一小会，他们将开始学习什么有效，什么无效。一旦他们更好地理解了它们，他们（希望）将采用更实用，更自然的方法来维护干净的代码，但不会产生70个char函数名称。

— 特拉斯坦
source

我原本是在写评论。我将给出的答案要多于要考虑的观点。但是，我绝对赞同“清晰代码”的做法，例如易于理解的命名和重构。

我一直不喜欢无注释规则，因为在某些情况下，必须使用注释来防止将来的代码损坏。通常应将它们限制在正在执行的操作以及执行的原因上。当代码做意外的事情或需要替换算法时，请谨慎使用它们。

在阅读或维护代码时，请考虑生产率。在代码的生命周期中，这比编写代码时的生产力更为重要。这些做法会有助于提高这些任务的生产率吗？

有了经验，这些实践应该变得根深蒂固，而不再是生产力的杀手。选择正确的名称可能会花费更长的时间，因为您正在澄清代码需要做什么。（这种澄清可能会使编码和调试更快。）这是否导致代码仅执行所需的功能或错误较少的代码？这对生产率有什么影响？

选择正确的方法名称所花费的时间很可能会立即得到回报，以便更好地了解该方法的目的。将方法名称“ iterateOverCustomers”与“ locateActiveCustomers”进行比较。哪一个传达了功能的意图？如有必要，哪个更容易重构？

— 比尔·索尔
source

我想指出，人们喜欢归因于Clean Code书的“无评论”规则实际上不在书中的任何地方。相反，整整一章都是关于评论的，上半部分用于描述许多类型的“好评论”，其后是“坏评论”部分。作者对此事的观点实际上比许多人认为的要合理得多。

— 艾瑞克·金

我一般在评论“无评论”规则。我曾使用过建议从语言定义中删除注释的语言。没有评论好坏。当时，我们在一段代码中加了注释，这在某些情况下是很可取的。有评论警告说是这种情况，此时不要添加新的代码块。

— BillThor

是的，对我来说，这似乎很极端。

— 艾瑞克·金