这 5 个让人窒息的烂代码,你看完都忍不了

作者 : 开心源码 本文共994个字,预计阅读时间需要3分钟 发布时间: 2022-05-14 共164人阅读

摘要:下面就为大家带来个人认为的常见的烂注释风格。

相信作为程序员的大家,只需写代码,就会自己写及看到别人写的代码注释。所以,我们往往会遇到“百花齐放,百家争鸣”般的注释。程序员最讨厌的10件事,0:写注释,1:别人不写注释。

作为一个老IT人,看了那么多年代码,也就看了那么多年注释。可以说,好代码不肯定有好注释,但烂代码基本和烂注释共存。下面就为大家带来个人认为的常见的烂注释风格,希望能对大家在日后的工作中,带来一丝丝的帮助。排名不分先后:

1.注释上带联络方式,TODO事项,问题单需求链接等。这种风格其实表现了工程师没有意识去利用好现代的平台技术,还停留在90年代的编码习惯。2020年了,git类软件已经是软件开发的首选代码托管平台了,问题单需求链接和联络方式的最佳位置应该是Git的提交日志上,TODO事项应该使用Git的issue管理。这种注释看到就应该删掉。例如以下两种注释

2.注释上带有一部分设计内容。这些内容最大的问题是,没人知道它是真是假,更没人知道它能否完整,删掉了吧,又有点可惜,万一有点用呢?不删吧,又看着不舒服。出现这种问题的最大起因是,团队内没有太好的地方承载这类文档。2020年了,可以试试Github的pages平台。

3.注释上写how,而不是why。这种大家都很清晰了,一致认为是不应该的。就不多说了,参考下面的例子

4.对代码的使用说明,例如方法如何调用,各项参数的说明,会抛出什么异常。例如以下的例子便是。有空写这种注释,还不如把测试用例写好,通过用例来告诉客户应该如何使用。

5.代码某种算法的特殊说明,这种比较有争议性,严格来说,不算是烂注释,但假如这种注释没有严格和代码一起管理(例如改了代码要同步改注释),那么这种注释就没有好过有了。所以这尽管严格来说是一个管理起因,但2020年了,我更推荐把这种注释写到提交日志上。怎样说呢?以Git的这段提交来说明这个问题,这段提交只设计到一个变量的非null判断,很多人可能就直接提交了,有些人也会在代码上加上注释,阐述为什么要做这个非null判断,但作者最终是选择了在提交日志上阐述这段逻辑,而且足足写了20行(刨去少量个人签名,有效行数也很多),想象一下把这20行写到代码中,会对代码的阅读产生多大的影响呀?但不写,又会对后面的维护带来问题。

本文分享自华为云社区《我的注释我做主》,原文作者:周大仙人 。

说明
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是摆设,本站源码仅提供给会员学习使用!
7. 如遇到加密压缩包,请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » 这 5 个让人窒息的烂代码,你看完都忍不了

发表回复