代码规范之注释该怎么写

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

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

  • (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. 【参考】好的命名、代码结构是自解释的,注释力求精简准确、表达到位。避免出现注释的一个极端:过多过滥的注释,代码的逻辑一旦修改,修改注释是相当大的负担。
文章目录
  1. 1. 一、回归正题,从我的理解上,注释该怎么写?
  2. 2. 二、那么从阿里巴巴Java开发手册上对于注释又是怎么描述的?
    1. 2.1. 1.【强制】类、类属性、类方法的注释必须使用 Javadoc 规范,使用/*内容/格式,不得使用// xxx 方式。
    2. 2.2. 2. 【强制】所有的抽象方法(包括接口中的方法)必须要用 Javadoc 注释、除了返回值、参数、异常说明外,还必须指出该方法做什么事情,实现什么功能。
    3. 2.3. 3. 【强制】所有的类都必须添加创建者和创建日期。
    4. 2.4. 4. 【强制】方法内部单行注释,在被注释语句上方另起一行,使用//注释。方法内部多行注释使用/ /注释,注意与代码对齐。
    5. 2.5. 5. 【强制】所有的枚举类型字段必须要有注释,说明每个数据项的用途。
    6. 2.6. 6. 【推荐】与其“半吊子”英文来注释,不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。
    7. 2.7. 7. 【推荐】代码修改的同时,注释也要进行相应的修改,尤其是参数、返回值、异常、核心逻辑等的修改。
    8. 2.8. 8. 【参考】谨慎注释掉代码。在上方详细说明,而不是简单地注释掉。如果无用,则删除。
    9. 2.9. 9. 【参考】对于注释的要求:第一、能够准确反应设计思想和代码逻辑;第二、能够描述业务含义,使别的程序员能够迅速了解到代码背后的信息。完全没有注释的大段代码对于阅读者形同天书,注释是给自己看的,即使隔很长时间,也能清晰理解当时的思路;注释也是给继任者看的,使其能够快速接替自己的工作。
    10. 2.10. 10. 【参考】好的命名、代码结构是自解释的,注释力求精简准确、表达到位。避免出现注释的一个极端:过多过滥的注释,代码的逻辑一旦修改,修改注释是相当大的负担。