Coding style 写评论是件坏事吗？

我一直在读一篇文章“干净代码摘要”

提到的一点是“注释最常见的原因之一是因为代码不好”

几年前，我了解到编写注释是一种很好的协作实践，可以让项目中的其他工作人员通过阅读注释了解类/函数/代码块等中发生的事情。我一直都知道，在团队中这样做是很周到的

---

我想澄清一下。

我认为这两种情况都可能发生。您可能会有合理的注释或注释，只是试图将混乱的代码变成可理解的代码

即使是最干净的代码（一个“不错”的代码）也可以从一些注释中获益。在可能的许多其他事情中，这些都有助于：

• 指示完成整个流程主要步骤的代码部分
• 澄清为什么在函数调用中使用某些值，而不是那么直观
• 帮助新合作者轻松理解代码的结构（例如，使用开源）
• 在实践中以不同方式执行某些程序时，说明技术细节

现在，这与你引用的句子并不矛盾。这句话并不意味着每次都有注释，这是因为代码不好。它只是说糟糕的编码是使用注释的一个很可能的原因，我觉得这很直观。制造“好”代码比制造“坏”代码需要更多/更好的技能，因此，制造“坏”代码并试图用注释填补漏洞的人可能比制造带有严格有用注释的整洁代码的人要多

---

因此，为了回答你的问题，我不认为写评论本身就是一件坏事。依靠注释来尝试纠正糟糕的编码实践将是一件坏事。

在我看来，代码应该是不言自明的。如果你读了它，它应该是富有表现力的，并且做你期望它做的事情。如果不清楚，评论可能会有帮助。但最终取决于你。我建议观看凯特·格雷戈里的一些演讲。虽然这是一个有趣的讨论，但没有“正确答案”这样的说法，因为这几乎完全是一个观点问题。在软件工程网站上可能会有一些关于它的问题。我同意@halfer。我觉得在写我的答案之前，这是一个意见的问题。然而，我决定继续发表，因为：（I）我发现怀疑是有效的，因此我认为至少提供一些论据来帮助OP采取一种姿态是公平的；（ii）我认为这也与所引用句子的解释有关，这可能使人认为应避免评论（这不是一个无可争辩的立场）；（iii）虽然我们不能说编写代码是好的，但我想到了多种情况，即使编写了良好的代码注释也可能有用；（四）空间。