注释的恰当用法是弥补我们在用代码表达意图是遭遇的失败。注释并不“纯然的好”，若代码有足够的表达力，则根本不需要注释。
1.注释不能美化代码：与其花时间编写解释糟糕代码的注释，不如花时间整理糟糕的代码。
2.用代码阐述：写注释前思考一下可否用函数来替代该注释，函数名称可体现相同的意义。
3.好注释：有些注释是必须的，也是有力的。
3.1).法律信息：公司代码规范要求编写与法律有关的注释，如版权及著作权声明，这些注释只要有可能就指向一份标准许可或其他外部文档，不需要详细列出。
3.2).提供信息的注释：解释函数作用的信息，这种注释也可以将其转换为代码，比如给函数名称重取一个有解释意义的名字。
3.3).对意图的解释：有时，注释不仅提供有关实现的有用信息，而且还提供了某个决定后的意图。
3.4).阐释：注释把某些晦涩难懂的参数或返回值的意义翻译为某种可读形式。
3.5).警示：用于警告其他程序员会出现某种后果的注释。
3.6).TODO注释：用//TODO形式在源代码中放置要做的工作列表。
3.7).放大：注释可以用来放大某种看来不合理之物重要性。
3.8).公共API中的doc：编写公共api需要有良好的doc。不过doc注释也和其他注释一样，可能会误导、不适用或提供错误信息。
4.坏注释：坏注释都是糟糕代码的支撑或借口，或者对错误决策的修正。
4.1).喃喃自语：如果决定写注释，就要花时间确保写出最好的注释，不要写出那种自认为需要而添加的注释。
4.2).多余的注释：注释不能提供比代码更多的信息就是多余的注释。
4.3).误导性注释；
4.4).循规性注释：并非所有的方法或变量都需要注释，遵循这样的规矩可能使代码散乱；
4.5).日志式注释：写注释来说明代码的历次修改，现如今都用源码系统管理代码后，这种注释已完全不需要了；
4.6).废话注释：毫无意义的注释，比如：默认构造函数上注释：/** Default Constructor*/
4.7).能用函数或变量时就不用注释；
4.8).位置标记：少用标记栏，只在少数有价值的地方添加标记，滥用也会让代码显得杂乱，没有意义；
4...括号后面的注释、归属与署名、注释掉的代码、HTML注释、非本地信息、注释信息过多，注释与代码没有明显联系、函数头（短函数不需要太多注释，取个好名字更重要）、