摘要：下面就为大家带来个人认为的常见的烂注释风格。
相信作为程序员的大家，只要写代码，就会自己写及看到别人写的代码注释。所以，我们往往会遇到“百花齐放，百家争鸣”般的注释。程序员最讨厌的10件事，0:写注释，1:别人不写注释。
作为一个老IT人，看了那么多年代码，也就看了那么多年注释。可以说，好代码不一定有好注释，但烂代码基本和烂注释共存。下面就为大家带来个人认为的常见的烂注释风格，希望能对大家在日后的工作中，带来一丝丝的帮助。排名不分先后：
1. 注释上带联系方式，TODO事项，问题单需求链接等。这种风格其实体现了工程师没有意识去利用好现代的平台技术，还停留在90年代的编码习惯。2020年了，git类软件已经是软件开发的首选代码托管平台了，问题单需求链接和联系方式的最佳位置应该是Git的提交日志上，TODO事项应该使用Git的issue管理。这种注释看到就应该删掉。例如以下两种注释
2. 注释上带有一部分设计内容。这些内容最大的问题是，没人知道它是真是假，更没人知道它是否完整，删掉了吧，又有点可惜，万一有点用呢吧，又看着不舒服。出现这种问题的最大原因是，团队内没有太好的地方承载这类文档。2020年了，可以试试Github的pages平台。
3. 注释上写how，而不是why。这种大家都很清晰了，一致认为是不应该的。就不多说了，参考下面的例子
4. 对代码的使用说明，例如方法如何调用，各项参数的说明，会抛出什么异常。例如以下的例子便是。有空写这种注释，还不如把测试用例写好，通过用例来告诉用户应该如何使用。
点击关注，第一时间了解华为云新鲜技术~
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！