一直以来我没有见过任何科学研究证明了这一点，但在软件领域，它就像一个教条或一个共同的信念。由于它的存在，将软件写得易于阅读、关注代码的可读型都是很重要的。通过一些技术的辅助程序员可以实现这些要求，这些技术其中之一就是写代码注释。

免责声明：我所说的“避免代码注释”并不意味着我不写注释，这意味着，我尽可能避免写代码注释，但当我觉得值得写时我还是写的。

“相比写软件我们花了更多的时间在阅读软件上”，一直以来我没有见过任何科学研究证明了这一点，但在软件领域，它就像一个教条或一个共同的信念。由于它的存在，将软件写得易于阅读、关注代码的可读型都是很重要的。通过一些技术的辅助程序员可以实现这些要求，这些技术其中之一就是写代码注释。

当谈论起代码注释的时候，有关的辩论总无休止。我们应该用注释来说明我们代码的作用吗，我们应该将重点放在代码的表达性而不需要注释来辅助阅读吗？Joe Kunk为这争论写了一篇博客 - 应不应该写注释。有那些人说文档完备的代码被认为是好代码，还有些人说应该避免注释，因为注释通常被用来解释/隐藏不好的代码。

在我看来，在书籍的影响下，为确保代码整洁便于重构，我们应该避免写注释，除非我们有一个好的写注释的理由（例如数学算法）或因为公司要求或流程我们有义务这样做。下面是我关于注释的五点忧虑。

我认为代码注释起到反作用的地方

1.注释往往鼓励坏的代码

“注释的代码是好代码”有这样一个说法，所以人们常常在代码中添加注释以代码漂亮。如果我们为了解释代码而添加注释这就像是一个信号：也许我们正在编写糟糕的代码。当我们要写一条注释是，我们应该想是否能够通过清理代码使它更有可读性呢。

2. 我们将花费更多的时间来编写和维护

注释通常是代码的第二个版本。当我们为一个函数写注释时我们实际在重复自己。我们违背了DRY（不要重复自己）原则。我们正在花费更多的时间且增加了复杂性。需求如果变了代码也要跟着变，如果我们写了注释也要随之更改。所以为多花费的一倍时间做出改变吧。我们可以利用这段时间来提高我们的代码或开发新的功能。

3. 注释是不可测试和验证的

当我们修改代码的时候我们借助诸如编译器、IDE及单元测试工具来辅助，注释没有，没有类似工具。你无法依靠工具或单元测试来确保它们的使用位置、日期标注等是正确的。一旦你写了一条注释，因为它是不可测试的无法关注它的准确性，一旦出错便会无法察觉的保留下来。

4. 与代码相比注释是不可靠的

通常当注释和代码脱离它就变得与没有多大意义了。如果程序员读到它就可能被误导。即使没有误导也需要通过阅读源码来搞清到底做了什么。一个实际的例子，如果我们的老板需要我们做一个修改，我们应该看注释还是代码呢？当然我们会看代码。

5. 注释占用了不少屏幕空间

一些注释方法（像下面的）占了很多行，当你想查看更多代码时这便成了一个问题。

/**

*

* @param title The title of the CD

* @param author The author of the CD

* @param tracks The number of tracks on the CD

* @param durationInMinutes The duration of the CD in minutes

*/

public void addCD(String title, String author,

int tracks, int durationInMinutes) {

CD cd = new CD();

cd.title = title;

cd.author = author;

cd.tracks = tracks;

cd.duration = duration;

cdList.add(cd);

}