代码命名言简意赅，函数短小职责单一，这些都做好了，那么接下来，我们看看，在实际开发中如何给我们的代码加上注释，写注释我们需要注意一些什么东西，来我们一起看看。
别给糟糕的代码加注释——重新写吧。
什么也比不上放置良好的注释来得有用。什么也不会比乱七八糟的注释更有本事搞乱一个模块。
如果编程语言足够有表达力，或者我们擅长使用这些语言来表达意图，就不那么需要注释——也许根本不需要。
注释的恰当用法是弥补我们在使用代码表达意图时遭遇的失败。注释总是一种失败，我们总无法找到不用注释就能表达自我的方法，所以总要有注释，这并不值得庆贺。
真实的地方只有一处：代码，只有代码能忠实告诉你它做的事情。所以，尽管有时也需要注释，我们也应该多花心思尽量减少注释量。
1、注释不能美化糟糕的代码
写注释的常见动机之一是糟糕的代码的存在。
像样的代码是带有少量注释的整洁的而有表达力的代码，与其花时间整理注释，不如花时间清理糟糕的代码。
2、用代码来阐述
使用函数来描述
3、好注释
有些注释是必须的，也是有利的。比如下面这些。
3.1 法律信息
版权及著作权声明等与法律有关的注释就是必要在每个源文件开头放置，有可能的话，最好将其指向一份标准许可或其他外部文档，而不是把所有条款放到注释中。
3.2 提供信息的注释
有时，用注释来提供基本信息也是有用处的，但最好的方式是尽量利用函数名称传递信息
3.3对意图的解释
注释有时还提供了某个决定后面的意图
3.4 阐释
注释把晦涩难明的参数或返回值的意义翻译为某种可读形式，更好的方法是尽量让参数或返回值本身就足够清楚。
3.5警示
有时，用于警告其他程序员会出现某种后果的注释也是有用的，不过多数的时候我们会利用适当解释性字符串@Ignore属性来关闭测试用例。
3.6TODO注释
TODO是一种表示应该做但还没有来得及做，功能代码有待编写，解释了函数的实现部分无所作为，需要定期查看，以免变成糟糕的代码。
3.7放大
注释可以用来放大某种看来不合理之物的重要性。
4、坏注释
大多数注释都是坏注释。通常，坏注释都是糟糕代码的支撑或借口，或者对错误决策的修订，基本上等于程序员自说自话。比如下面这些：
4.1喃喃自语
如果单凭自己感觉或者因为过程需要就添加注释，那是无谓之举，如果写注释就应该出时间写出最好的注释。
4.2多余的注释
无法比代码本身提供更多的信息属于多余信息。
4.3误导性注释
注释不够精确，无法表达其真实含义，容易引起误导。
4.4循规式注释
单纯依照范式来写注释全然是愚蠢可笑的，徒然让代码变得散乱。
4.5日志式注释
不需要每一次修改都增加一条注释，不然会让代码变得凌乱不堪。
4.6废话注释
对很显然、很容易理解的还添加注释，纯粹是废话注释。
用整理代码的决心替代创造废话的冲动，你会变得更加优秀。
4.7可怕的废话
全然无用，都是废话。
4.8能用函数或变量时就别用注释
4.9位置标记
尽量少用标记栏，只有在特别有价值的时候用，如果滥用，容易被忽略。
4.10括号后面的注释
括号后面的注释会让人觉得函数太长，应该做的是缩短函数。
4.11归属与署名
归属与签名无必要，容易搞糟代码。
4.12注释掉的代码
直接把代码注释掉是不好的做法，容易造成严重后果，后续的人不懂如何处理。
4.13HTML注释
源代码中注释HTML标记是错误的做法，造成难以阅读。
4.14非本地信息
注释应该确保写在离它最近的代码处，不要在本地注释上下文出现系统级信息。
4.15信息过多
别在注释中添加有趣的历史性话题或无关的细节描述。
4.16不明显的联系
注释及其描述的代码之间应该表现出显而易见的联系。
4.17函数头
给短函数选个好名字比写注释强。
4.18非公共代码的javadoc
给非公共用途的代码写注释是不应该的，会令人厌烦。
4.19范例
注释使用量合适并都足具说明意义。
综上所述，我们知道了什么是好的注释，什么是坏的注释，我们既需要注释又要避免注释，这是一个矛盾体，其实生活本来就是矛盾的，我们需要做的是，在这其中找到平衡点，如何写好注释是一门艺术，最好的注释是代码，后续为大家继续介绍如何写好注释。