摘要：下面就为你们带来我的认为的常见的烂注释风格。
相信做为程序员的你们，只要写代码，就会本身写及看到别人写的代码注释。因此，咱们每每会遇到“百花齐放，百家争鸣”般的注释。程序员最讨厌的10件事，0:写注释，1:别人不写注释。git
做为一个老IT人，看了那么多年代码，也就看了那么多年注释。能够说，好代码不必定有好注释，但烂代码基本和烂注释共存。下面就为你们带来我的认为的常见的烂注释风格，但愿能对你们在往后的工做中，带来一丝丝的帮助。排名不分前后：程序员
1. 注释上带联系方式，TODO事项，问题单需求连接等。这种风格其实体现了工程师没有意识去利用好现代的平台技术，还停留在90年代的编码习惯。2020年了，git类软件已是软件开发的首选代码托管平台了，问题单需求连接和联系方式的最佳位置应该是Git的提交日志上，TODO事项应该使用Git的issue管理。这种注释看到就应该删掉。例如如下两种注释github
2. 注释上带有一部分设计内容。这些内容最大的问题是，没人知道它是真是假，更没人知道它是否完整，删掉了吧，又有点惋惜，万一有点用呢？不删吧，又看着不舒服。出现这种问题的最大缘由是，团队内没有太好的地方承载这类文档。2020年了，能够试试Github的pages平台。算法
3. 注释上写how，而不是why。这种你们都很清晰了，一致认为是不该该的。就很少说了，参考下面的例子测试
4. 对代码的使用说明，例如方法如何调用，各项参数的说明，会抛出什么异常。例如如下的例子即是。有空写这种注释，还不如把测试用例写好，经过用例来告诉用户应该如何使用。编码
5. 代码某种算法的特殊说明，这种比较有争议性，严格来讲，不算是烂注释，但若是这种注释没有严格和代码一块儿管理（例如改了代码要同步改注释），那么这种注释就没有好过有了。因此这虽然严格来讲是一个管理缘由，但2020年了，我更推荐把这种注释写到提交日志上。怎么说呢？ 我以Git的这段提交来讲明这个问题， 这段提交只设计到一个变量的非null判断，不少人可能就直接提交了，有些人也会在代码上加上注释，阐述为何要作这个非null判断，但做者最终是选择了在提交日志上阐述这段逻辑，并且足足写了20行（刨去一些我的签名，有效行数也不少），想象一下把这20行写到代码中，会对代码的阅读产生多大的影响呀？但不写，又会对后面的维护带来问题。spa
本文分享自华为云社区《个人注释我作主》，原文做者：周大仙人 。