代码规范之注释该怎么写

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了代码规范之注释该怎么写，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含4137字，纯文字阅读大概需要6分钟。

内容图文

有人说，代码即注释，也就是通过你的代码就能看得懂你的代码逻辑是什么。但是对于大多数人来说，这有些不切实际，每个公司的研发团队成员的能力是不一样的，有的能力强，有的能力弱，能力强的体现在能解决若干问题，但是在编码规范方面却有待提高，能力弱的，有的能力弱的在代码规范方面却比所谓的能力强的要好得多，这里的”能力强”并不是指两个人的聪明才智差异很大，而是指特定领域的积累，有的积累得多，经验丰富，有的积累的少，经验不那么丰富。但因为是一个团队，就必须要有一定的约束，不仅仅是对能力强的，能力差也一样，一视同仁，团队不能搞单兵作战，那样就失去了团队的意义。

近来我不断思考一件事情，如何将代码注释写的更好，过去待了好几家公司，我写代码对于注释的态度如下:

• (1)有时间就写，没时间后面再说(实际等于不写任何注释)；
• (2)针对特定接口、类、方法写一些概要注释(也就是解释该接口、类、方法是做什么的)；
• (3)针对复杂的逻辑，写注释，自上而下。

但是最终做的最多的还是(1)，哪怕有的时候工作中有一定的空闲时间，我所想的并不是如何将以往没写注释的补充一下注释，而是了解研究现在的新技术(流行的编程语言或Java相关的框架组件等)。

这样做的最后结果是，代码可读性越来越差，可读性差导致的扩展性也就越来越差，可读性跟可扩展性有一定的相关性。

举个例子:
在开发时间紧迫的时候，面对新的功能，看到以往有类似的功能，通常我们的做法是将其复制过来，改了一些，测试了一下，功能输出结果，符合预期，然后就不管了，下次再遇到类似的功能，仍然采取该做法。突然某一天，经理说这个新的功能里面要加一些附加小功能，并同时跟这个类似的都全部加上，由于我们之前习惯了复制黏贴，这时对于我们无疑是毁灭性打击，只能拼命加班加点弄了(从这一刻，我明白了码农是如何养成的)。
假设我们有这样一个习惯，面对重复两次或三次以上的功能代码，我们可将其抽取成一个通用方法(针对类似的功能)，一方面，代码可重用性增强，另一方面减少不必要的代码量，最后一方面，未来如果需要加扩展，我们只需改动这一个方法即可，同时我们写注释，将这一方法写清楚即可。最近我迫使自己养成这样的一个习惯，面对好几个功能模块，我发现轻松了很多，工作效率也大大提升。

一、回归正题，从我的理解上，注释该怎么写？

• (1)复杂的逻辑应有一个流程图(可以是visor图、也可以是txt或word、思维导图等)，按照流程图在对应的代码上写下注释；
• (2)接口、类、方法都需要写注释(这个注释通常包含作者、时间、描述等通用，可通过IDEA模板实现)，针对特定的方法，最好使用多行注释，按照数字顺序进行列举；
• (3)参考开源项目是如何写注释的(如Java、Spring全家桶相关的框架等)；
• (4)方法内部逻辑上，尽量减少注释，如果方法内部逻辑太长，一大堆注释，像写作文似的，改一个地方，需要整体看一遍，结合(1)和(2)或(2)。

二、那么从阿里巴巴Java开发手册上对于注释又是怎么描述的？

1.【强制】类、类属性、类方法的注释必须使用 Javadoc 规范，使用/*内容/格式，不得使用// xxx 方式。

说明：在 IDE 编辑窗口中，Javadoc 方式会提示相关注释，生成 Javadoc 可以正确输出相应注释；在 IDE 中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高
阅读效率。

2. 【强制】所有的抽象方法（包括接口中的方法）必须要用 Javadoc 注释、除了返回值、参数、异常说明外，还必须指出该方法做什么事情，实现什么功能。

说明：对子类的实现要求，或者调用注意事项，请一并说明。

3. 【强制】所有的类都必须添加创建者和创建日期。

4. 【强制】方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释使用/ /注释，注意与代码对齐。

5. 【强制】所有的枚举类型字段必须要有注释，说明每个数据项的用途。

6. 【推荐】与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。

反例：“TCP 连接超时”解释成“传输控制协议连接超时”，理解反而费脑筋。

7. 【推荐】代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改。

说明：代码与注释更新不同步，就像路网与导航软件更新不同步一样，如果导航软件严重滞后，就失去了导航的意义。

8. 【参考】谨慎注释掉代码。在上方详细说明，而不是简单地注释掉。如果无用，则删除。

说明：代码被注释掉有两种可能性：1）后续会恢复此段代码逻辑。2）永久不用。前者如果没有备注信息，难以知晓注释动机。后者建议直接删掉（代码仓库保存了历史代码）。

9. 【参考】对于注释的要求：第一、能够准确反应设计思想和代码逻辑；第二、能够描述业务含义，使别的程序员能够迅速了解到代码背后的信息。完全没有注释的大段代码对于阅读者形同天书，注释是给自己看的，即使隔很长时间，也能清晰理解当时的思路；注释也是给继任者看的，使其能够快速接替自己的工作。

10. 【参考】好的命名、代码结构是自解释的，注释力求精简准确、表达到位。避免出现注释的一个极端：过多过滥的注释，代码的逻辑一旦修改，修改注释是相当大的负担。

内容总结

以上是互联网集市为您收集整理的代码规范之注释该怎么写全部内容，希望文章能够帮你解决代码规范之注释该怎么写所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---