给代码写注释时有哪些讲究?

简介: 给代码写注释时有哪些讲究?

如果领导给你一个项目的源码让你阅读,并理解重构代码,但里面一句注释都没有,我想这肯定是之前同事“删库跑路”了。


看一份源码什么很重要?除了各种代码规范之外,还有一个比较重要的就是注释。注释虽然写起来很痛苦, 但对保证代码可读性至关重要,下面我们就以C/C++代码规范注释为例,将描述如何注释以及有哪些讲究。


1、注释风格


  • 总述

 一般使用 // 或 /* */,只要统一就好。

  • 说明

 // 或 /* */ 都可以,但团队要在如何注释及注释风格上确保统一。


2、文件注释


  • 总述在每一个文件开头加入版权、作者、时间等描述。


 文件注释描述了该文件的内容,如果一个文件只声明,或实现,或测试了一个对象,并且这个对象已经在它的声明处进行了详细的注释,那么就没必要再加上文件注释,除此之外的其他文件都需要文件注           释。

  • 说明

 法律公告和作者信息:每个文件都应该包含许可证引用。也要为项目选择合适的许可证版本(比如, Apache 2.0, BSD, LGPL, GPL)。

  • 文件内容

 如果一个 .h 文件声明了多个概念, 则文件注释应当对文件的内容做一个大致的说明, 同时说明各概念之间的联系。一个一到两行的文件注释就足够了, 对于每个概念的详细文档应当放在各个概念中, 而不是文         件注释中。


 不要在 .h 和 .cc 之间复制注释, 这样的注释偏离了注释的实际意义。


 最后再举个最简单的实际例子:

image.png


3、函数注释


  • 总述

 函数声明处的注释描述函数功能; 定义处的注释描述函数实现。

  • 说明

 函数声明:基本上每个函数声明处前都应当加上注释, 描述函数的功能和用途。只有在函数的功能简单而明显时才能省略这些注释(例如, 简单的取值和设值函数)。


 比如:

image.png


函数定义:

如果函数的实现过程中用到了很巧妙的方式, 那么在函数定义处应当加上解释性的注释。比如, 你所使用的编程技巧, 实现的大致步骤, 或解释如此实现的理由。举个例子, 你可以说明为什么函数的前半部分要加锁而后半部分不需要。

不要 从 .h 文件或其他地方的函数声明处直接复制注释. 简要重述函数功能是可以的, 但注释重点要放在如何实现上。


4、变量注释


  • 总述

 通常变量名本身足以很好说明变量用途, 某些情况下, 也需要额外的注释说明。

  • 说明

 根据不同场景、不同修饰符,变量可以分为很多种类,总的来说变量分为全局变量、局部变量。


 一般来说局部变量仅限于局部范围,其含义相对简单容易理解,只需要简单注释即可。


 全局变量一般作用于多个文件,或者整个工程,因此,其含义相对更复杂,所以在注释的时候,最好描述清楚其具体含义,就是尽量全面描述。


 (提示:全局变量尽量少用)


5、拼写注释


  • 总述

 可能一个变量、一个函数包含的意思非常复杂,需要多个单词拼写而成,此时对拼写内容就需要详细注释。

  • 说明

 注释的通常写法是包含正确大小写和结尾句号的完整叙述性语句。大多数情况下, 完整的句子比句子片段可读性更高。短一点的注释, 比如代码行尾注释, 可以随意点, 但依然要注意风格的一致性。


 同时,注释中的拼写、逗号也很重要。虽然被别人指出该用分号时却用了逗号多少有些尴尬, 但清晰易读的代码还是很重要的。正确的标点, 拼写和语法对此会有很大帮助


6、TODO 注释


  • 总述

 对那些临时的, 短期的解决方案, 或已经够好但仍不完美的代码使用 TODO 注释。TODO 注释要使用全大写的字符串 TODO, 在随后的圆括号里写上你的名字, 邮件地址, bug ID, 或其它身份标识和与这一 TODO 相关的 issue。主要目的是让添加注释的人 (也是可以请求提供更多细节的人) 可根据规范的 TODO 格式进行查找。添加 TODO 注释并不一定意味着你要自己来修正, 因此当你加上带有姓名的 TODO 时, 一般都是写上自己的名字。


7、结 语


注释固然很重要, 但最好的代码应当本身就是文档,有意义的类型名和变量名, 要远胜过要用注释解释的含糊不清的名字。


你写的注释是给代码阅读者看的, 也就是下一个需要理解你代码的人. 所以慷慨些吧, 下一个读者可能就是你!

目录
相关文章
|
4月前
|
设计模式 算法 前端开发
有什么可以减少注释,但依然能让他人看得懂代码的方法吗?
有什么可以减少注释,但依然能让他人看得懂代码的方法吗?
30 0
|
2月前
|
前端开发 测试技术
代码注释怎么写:让你的代码更易维护
在编程中,有一种无声的艺术,那就是代码注释。这可能看起来微不足道,但其实非常关键。它不仅有助于他人理解你的代码,也是自我表达的一种方式。
|
2月前
|
算法 IDE 程序员
不写注释就是耍流氓?
不写注释就是耍流氓?
17 0
|
2月前
|
数据可视化 测试技术
测试范围不清晰该咋办?
测试范围不清晰该咋办?
|
4月前
|
Java
注释之背后:代码的解释者与保护者
注释之背后:代码的解释者与保护者
21 0
|
9月前
|
程序员
相见恨晚的Matlab编程小技巧(2)-代码怎么做到逻辑清晰?——巧用注释符“%“
        本文将以教程的形式详细介绍Matlab中两个常用符号“%”和“%%”的作用。初学者可以通过此文掌握这两个符号的用法,为Matlab编程打下坚实的基础。
|
设计模式 自然语言处理 程序员
一场关于代码注释的争执,引发的三点思考
在一次研发沟通会上,大家关于是否需要代码注释做了一番争执(讨论)。
一场关于代码注释的争执,引发的三点思考
|
设计模式 安全 Java
条件语句的多层嵌套问题优化,助你写出不让同事吐槽的代码
前言《阿里巴巴开发手册》中,有关于多 if-else 分支和嵌套的建议和解决方案,如下:那么本文介绍几种优化方案,给大家提供一些思路案例下面是开发中可能会遇到的典型代码:这种情况,我们如何替代多分支和分支嵌套问题呢?如何让代码变得更容易维护和拓展呢?可以先自己思考一下哈..........下面我提供几种方法吧卫语句《重构--改善既有代码的设计》 书籍中有有如下描述:如果某个条件极其罕见,就应该单独检查该条件,并在条件为真时立即从函数中返回。这样的单独检查常常被称为 “卫语句”。使用卫语句,我们可以对上面的示例修改为:先进行条件检查,然后将 if-else 逻辑转成对应的卫语句格式。枚举《Eff
|
机器学习/深度学习 Unix 程序员
给代码写注释时有哪些讲究?
  如果领导给你一个项目的源码让你阅读,并理解重构代码,但里面一句注释都没有,我想这肯定是之前同事“删库跑路”了。   看一份源码什么很重要?除了各种代码规范之外,还有一个比较重要的就是注释。   注释虽然写起来很痛苦, 但对保证代码可读性至关重要,下面我们就以C/C++代码规范注释为例,将描述如何注释以及有哪些讲究。   1 注释风格   1. 总述   一般使用 //或/* */,只要统一就好。   2. 说明   //或/* */都可以,但团队要在如何注释及注释风格上确保统一。   2 文件注释
222 0
|
设计模式 缓存 前端开发
可否举例说明你在工作中是如何优化前端代码的?
可否举例说明你在工作中是如何优化前端代码的?
157 0