“Comment or not comment, that is the question”
01.注释的目的和原则
purpose
- 提高代码的可读性,从而提高代码的可维护性
principle
- 如无必要,勿增注释 ( As short as possible )
- 如有必要,尽量详尽 ( As long as necessary )
代码是写给维护者看的,只是偶尔的在服务器上运行
好的代码会给自己注释而无需多加说明,本身就拥有较高的可读性。例如:
1 | // bad |
02.什么是好注释,什么是坏注释
好的注释包括:
- 帮助读者更好地了解代码逻辑和结构,例如:
1 | init: function() { |
- 特殊或不易理解写法的解释说明,例如:
1 | /** |
- 特殊标记注释:如 TODO、FIXME 等有特殊含义的标记
- 文件注释:部分规约会约定在文件头部书写固定格式的注释,如注明作者、协议等信息
- 文档类注释:部分规约会约定 API、类、函数等使用文档类注释(如 jsdoc 风格)
- 遵循统一的风格规范,如一定的空格、空行,以保证注释自身的可读性
坏的注释包括:
- 注释对阅读代码无益:如本文第一个示例,本可以不用注释,用清晰的命名、逻辑进行代码自注释
- 未遵循统一的风格规范:如单行注释长度、空格、空行,例如:
1 | // bad 单行注释过长,不易阅读,应写成多行 |
- 情绪性注释:如抱怨、歧视、搞怪等
03.如何写好注释
注释规约
理解注释的目的和原则,制定并遵循一份注释规约,以保证注释的可读性和一致性
工具保障
比如使用 ESLint 保证注释风格的一致,使用 Sonar 检查项目注释率
04.注释规约
4.1 【推荐】单行注释使用 //
注释应单独一行写在被注释对象的上方,不要追加在某条语句的后面:
1 | // bad |
注释行的上方需要有一个空行(除非注释行上方是一个块的顶部),以增加可读性:
1 | // bad |
4.2 【推荐】多行注释使用 /* … /,而不是多行的 //
1 | // bad |
4.3 【强制】注释内容和注释符之间需要有一个空格,以增加可读性。eslint: spaced-comment
1 | // bad |
4.4 【推荐】使用特殊注释标记
有时我们发现某个可能的 bug,但因为一些原因还没法修复;或者某个地方还有一些待完成的功能,这时我们需要使用相应的特殊标记注释来告知未来的自己或合作者。常用的特殊标记有两种:
- // FIXME: 说明问题是什么
- // TODO: 说明还要做什么或者问题的解决方案
1 | class Calculator extends Abacus { |
4.5 【推荐】文档类注释,如函数、类、文件、事件等,使用 jsdoc 规范
例如:
1 | /** |
05.工具
我们可以使用一些工具来保证注释质量,例如:
Eslint:保证一致的注释风格
ESLint 中有一些注释相关的规则,用户可选择开启:
- valid-jsdoc
- require-jsdoc
- no-warning-comments
- capitalized-comments
- line-comment-position
- lines-around-comment
- multiline-comment-style
- no-inline-comments
- spaced-comment