诸位对“好的代码就是要注释比代码还多”这句话怎么看？

注释是写为什么，而不是写是什么

你像 Java 那个 toString ，我表示不可以，一大片绿油油的注释里面夹点代码，readability 为负

如果需要大量的注释去解释一段代码，那这段代码可能就需要重构了；好的代码，代码本身就是注释了。

其实作为中国人，我对汉语的敏感度更高，所以我写中文注释，也喜欢看有注释的代码

建议评论区的高手以后都尽量别写注释了😄

方法名或者参数名写的再好，我还是不如中文注释来的敏感

要分清以注释面貌出现、给 external caller 看的文档，和不做为文档、给 internal maintainer / reviewer 看的真正注释

@AyaseEri 别说 Java 了，Java 的文档机制是很完善的，IDE 的支持也很好。楼上没有开阅读模式，而且对于标准库文档我认为越详细越好。

@cmdOptionKana 虽然但是， 这不是一句，原文是两句

对于商业项目，如果有 JIRA 或者 AzureDevOps 等卡墙支持，可以考虑在 commit 中指定卡号。这样看起来有疑问的代码就直接去看 commit 记录及相关联的卡。

业务代码经常修改的不建议写注释，底层代码还是要尽量写单元测试和丰富的注释。

这个得看 ROI 。
如果一段代码预期会被很多人看，比如面向外部的、基础的、框架性质的代码，那么不仅要解释每个参数的含义，还要说明使用场景。甚至按照文档生成工具的标准单独生成文档。
如果一段代码只有开发者看，那么把代码写好就行，实在无法自解释的逻辑加注释。
如果一段代码除了自己谁都不看，比如就自己用的小脚本，那想怎么写怎么写。

业务代码非常容易出现代码和逻辑改了，注释没同步这种事情。看做的是什么类型的。

资本阶级给无产阶级灌输的观念罢了

大部分人写的就是一坨屎，还以为自己是好代码不写注释。

代码本身就在表达你的逻辑

代码自注释就是扯淡，代码命名、结构好，只能自解释流程，业务细节呢？算法细节呢？不注释看毛线呢

对这句话的理解是，需要加上限制条件“在增删改查领域”。稍微运用点算法或者设计，没有注释，也许能看懂，但是有注释可以让看懂的时间缩短到 10%内

不少人比较高估自己拉💩的水平，不写注释，怕不是隔了一年，自己都不敢动💩

我有强迫症就喜欢写注释