为什么我不建议你写注释?

前言

实际上,注释最多也就是一种必须的恶。若编程语言足够有表达力，或者我们擅长于用这些语言来表达意图，就不那么需要注释了，甚至也许根本不需要。 注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败，我用了失败一词，其实是说真的。注释总是一种失败，是因为我们无法找到不用注释就能表达这段代码含义的方法。 如果你发现你的代码需要写注释，那么你就应该想想是不是有办法翻盘，用代码来表达。并不是不让你真的不用注释，而是有些时候，用注释是因为我们怕其他的开发者在我们的代码的时候，看不懂我们的代码从而去加注释，那么我们为什么不写出其他开发者一目了然的代码呢？

为什么不建议写注释？

为什么我们极力贬低注释？因为注释跟代码一样，注释会撒谎，但这并不是我们有意的写一些撒谎的注释。我们可以想象一个项目如果做了一年两年三年，代码的业务逻辑永远都不会改变吗？不可能……. 注释存在的时间越久，就离其所之前描述的代码越远，越来越久就会变得全然错误。为什么呢？因为程序员不能坚持维护注释。 代码在变动，在演化。从这里移到那里。彼此分离、重构又合到一起，而注释却不一定就会随着代码的移动重构而移动重构，慢慢的，业务逻辑改了，注释则会与代码分隔，时间很长了就不准确了。所以，只有代码，代码才能确定的告诉你，它做了什么事，代码才是唯一的信息来源。所以，尽管有时候也需要注释，我们也该多花心思尽量减少注释量。

注释美化代码？

写注释的常见动机之一是因为糟糕代码的存在，我们编写一个方法，写完之后发现这个方法内容乱七八糟，这个时候我们可能会告诉自己，在上面写点注释！但是错了，最好的方法是让代码变得干净！ 带有少量注释的整洁而有表达力的代码，比带有大量注释的零碎而又复杂的代码像样的多，与其花时间编写解释你写的代码的注释，倒不如花时间清洁你那堆糟糕的代码。

如何用代码来阐述？

你愿意看到这个?

// check to see if the employee is eligible for full benefits 
if ((employee.flag & HOUTLY_FLAG) && employee.age > 65) {

}

还是愿意看到这个?

if (employee.isEligibleForFullBenefits()) {
}

能用代码解释你的意图,就不用去写注释,很多时候我们只需要想上几秒钟,简单到只需要创建一个描述与注释表达出同一事物的函数即可。 有些注释是必须的也是有利的，不过，唯一真正好的注释是你想办法去把你想表达的事物用代码表达出来。 然而有些时候，一些废话的注释我们不要去写 比如

public class Demo {

   // Default constructor
    public Demo () {

    }


}

甚至

/**
*Return the day of the month
**/
pubilc int getDayOfMonth () {

}