别给糟糕的代码加注释， ---重新写
如果编程语言足够有表达力，或我们长于用这些语言来表达意图，就不那么需要注释。注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。
编写优美的代码，尽量减少注释量
- 注释不能美化糟糕的代码
编写带有少量（或没有）注释的整洁而有表达力的代码
- 用代码来阐述
不要用注释来理解代码，让代码更具表达力
- 好注释
有些注释是必须的，也是有利的。
3.1 法律信息
3.2 提供信息的注释
3.3 对意图的解释
3.4 阐释 把某些晦涩难明的参数或返回值的意义翻译为某种可读形式。
3.5 警示 用于警告其他程序员会出现某种后果
3.6 TODO注释 用//TODO的形式在源代码中放置要做的工作列表。
3.7 放大 注释可以用来放大某种看来不合理之物的重要性。
3.8 公共API中的Javadoc /* /
- 坏代码
通常坏注释都是糟糕的代码的支撑或接口，或对错误决策的修正
4.1 喃喃自语 如果只是因为你觉得应该或者因为过程需要就添加注释
4.2 多余的注释
4.3 误导性注释 注释不够准确
4.4 循规式注释 并不是每个函数都要Javadoc 每个变量都要注释
4.5 日志式注释 每次编辑代码是在模块开始出添加一条注释。在现在有版本控制系统时，会让模块变得凌乱不堪 目前用的少了。
4.6 废话注释
4.7 可怕的废话 Javadoc的废话
4.8 能用函数或变量时就别用注释
4.9 位置标记
4.10 括号后面的注释 分离函数
4.11 归属与署名
4.12 注释掉的代码 直接把代码注释掉是讨厌的做法。直接删掉。不然后来人不敢删除
4.13 HTML注释 源代码中加入html注释影响理解
4.14 非本地信息 注意注释要离它的代码最近
4.15 信息过多 别在注释中添加有趣的历史性话题或者无关的细节描述
4.16 不明显的联系 注释与代码之间联系应该显而易见
4.17 函数头 写好的函数名的重要性
4.18 非公共代码中的Javadoc 如果函数不当作公共方法类就不要写Javadoc
