注释写得烂，不如不写
第五章聊"注释"，这章看得我手心冒汗——那些年写过的"此处省略100字"注释，简直是公开处刑。
注释是无奈的妥协，不是加分项
作者一句话戳破真相："注释最多是一种必须的恶"。确实，好代码本身就会说话，需要注释来解释的代码，往往已经烂了一半。
想起之前维护的代码里有个注释：// 这个循环很复杂，别改。现在才反应过来，这不是提醒，是投降——承认自己写得烂，还不让别人改。真正的整洁代码，应该让注释显得多余。
哪些注释值得写？救命的那种
不是所有注释都该删，这几种情况确实需要：
- 法律信息：版权声明这种躲不掉，总不能让律师去读代码逻辑
- 警示信息：
// 这里改了会影响订单支付，小心！这种能救命 - TODO注释：
// 等支付接口升级后，这里要换加密方式相当于贴便利贴 - 公共API文档：Javadoc这种给别人用的，还是得写清楚参数和返回值
但要注意，这些注释也会过期。之前见过一段注释说"这个值最大100"，结果代码里早改成1000了，新人照着注释改出一堆bug。注释和代码必须同步更新，否则不如没有。
那些年踩过的注释坑，你中了几个？
作者列的"坏注释"清单，我几乎全中过：
- 喃喃自语型：
// 循环开始了// 这里加1纯属废话，不如代码本身清楚 - 多余解释型：给变量
userName加注释// 用户名，纯属画蛇添足 - 误导型：注释说"这是用户ID"，实际代码里存的是手机号，坑死后人
- 注释掉的代码：最可怕的是一大段注释掉的代码，没人敢删，越积越多
最离谱的是见过有人用HTML写注释，<b>重要</b>这种，在IDE里看像乱码。注释的目的是解释代码，不是秀操作。
用代码代替注释，才是真本事
作者说"最好的注释是你想办法不去写的注释"。深以为然。比如这段代码：
// 反例：用注释解释逻辑
if ((employee.flags & HOURLY_FLAG) && (employee.age > 65)) {
// 检查员工是否符合全额福利条件
}
// 正例：用代码说明意图
if (employee.isEligibleForFullBenefits()) {
}
后者根本不需要注释，函数名就是最好的解释。能通过重命名、拆函数解决的问题，别用注释。
想起自己之前写过的一段复杂计算，加了三行注释才说明白。后来重构时拆成了calculateBasePrice()、addTax()、applyDiscount()三个函数，注释全删了，反而更清楚。
最后清理了一波注释
翻了翻自己最近的代码，删掉了这些注释：
- 所有解释"这段代码在干嘛"的（改成函数名说明）
- 所有和代码重复的（比如
// 用户名注释userName变量） - 所有注释掉的代码（直接删，Git里能找到历史）
结果代码清爽了不少，读起来反而更快。突然明白：写注释的最高境界，是让读者意识不到有注释。
（下一章讲代码格式，想起自己时而缩进2格时而4格的代码，感觉又要被教育了...）
