4. 注释
别给糟糕的代码加注释--重新写吧
注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。
注释总是一种失败。我们总无法找到不用注释就能表达自我的方法，所以总要有注释，这并不值得庆祝。
注释会撒谎。注释存在的时间越久，就离其所描述的代码越远，越来越变得全然错误。原因很简单，程序员不能坚持维护注释。
只有代码能忠实地告诉你它做的事。那是唯一真正准确的信息来源。所以，尽管有时也需要注释，我们也该多花心思尽量减少注释量。
4.1 注释不能美化糟糕的代码
写注释的常见动机之一是糟糕代码的存在。我们编写一个模块，发现它令人困扰，乱七八糟。我们知道，它烂透了。我们告诉自己：“喔，最好写点注释！”不！最好是把代码弄干净！！！
与其花时间编写解释你搞出的糟糕的代码的注释，不如花时间清洁那堆糟糕的代码。
4.2 用代码来阐述
写注释之前，花几秒钟想想。很多时候，简单到只需要创建一个描述与注释所言同一事物的函数即可。你愿意看到这个：
// check to see if the employee is eligible for full benefits
if((employee.flags & HOURLY_FLAG) && (employee.age > 65))
还是这个？
if(employee.isEligibleForFullBenefits())
下面的代码不是会简洁很多？而且对于不需要关注具体判断逻辑的代码阅读者来说，下面的代码也更便于理解。
4.3 好注释
当然，有些注释是必须的，也是有利的，来看一看值得写的注释：
- 法律信息
- 提供信息的注释
- 对意图的解释
- 阐述
- 警示或者提醒
- TODO 注释
- 放大：注释可以用来放大某种看起来不合理之物的重要性
4.4 坏注释
书中提到了很多不好的注释，在我看来常见不好的注释总结就以下几种：
- 废话注释：代码能解释还写注释
- 误导性注释
- 位置标记：在代码中想标记位置，使用
// --------- Actions ------------ - 注释掉的代码：既然已经注释掉代码了，就不要不敢去删除
