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

[nuanshen]

[thetbw]

有些算法可能没有多少注释，变量命名清晰就行，所谓文档就是扔一篇论文给你

[daimubai]

注释只写是什么和为什么。如果函数名足够清晰，是什么也可以不写。

[zhazi]

注释本身没什么问题。可问题是百分之 90 的人不会写注释。
我看到注释大多类似这样

//这是一只猫
class Cat{}

[Building]

你注释还没写完，人家需求都改了三遍了，业务类代码和人家框架类代码有什么好比的，业务类只要在有需要解释的地方注释一下为什么这么做就行了

[nothingistrue]

敏捷开发出来前，（瀑布式开发年代）这是金科玉律。敏捷开发出来后，这是老顽固和不懂的人才说得出来的话。这里专门指的是代码注释，不包括 Javadoc 这种文档注释。

最后提一点，有没有注释还是好坏的差别，注释跟代码不同步，那是正常跟错误的区别。

[rrZ2C]

哈哈,我是真希望 aosp 注释再多一点

[zhazi]

代码谁都会看，好的注释会告诉你为什么作者会写出以下代码。而不是通过注释重新描述一遍代码

[ebushicao]

注释多没用，写的对才有用，有些光写些废话，还不如不写。比如：const sum = a + b; // 将 a 和 b 相加

[Huelse]

如果是具有通用性或基础性的代码，当然是有用的注释越多越好

[fredli]

好代码是命名规范，逻辑清楚，测试完备，bug free

[qingshuang]

虽然我们老讲开闭原则，但是在业务开发中很多地方代码都是需要修改的，但是经常代码被改了，注释没改，这样注释反而有误导信息，所以会说用代码来代替注释。。

[Huelse]

比较赞同楼上说的，为什么要写这段代码，可能的改进或可能的问题等，而不是光写这段代码干了啥，例如：获取...，计算...

[ryougifujino]

业务代码注释反而应该少，且应该自注释。Clean Code 里也说到过：“我为什么要极力贬低注释？因为注释会撒谎。也不是说总是如此或有意如此，但出现得实在太频繁。注释存在的时间越久，就离其所描述的代码越远，越来越变得全然错误。原因很简单。程序员不能坚持维护注释。
代码在变动，在演化。从这里移到那里。彼此分离、重造又合到一处。很不幸，注释并不总是随之变动——不能总是跟着走。注释常常会与其所描述的代码分隔开来，孑然飘零，越来越不准确。”

库代码因为变动程度没那么大，而且有些文档又是根据注释来生成的，所以你会看到大段的注释。

[elintwenty]

1. 好的开源代码尤其基础类库会写大量注释，包含如何使用、应用背景、关键依赖关系、注意事项等等
2. 差的业务代码可能注释得不到更新，看的人看到的都是过时的、错误的注释，这样还不如没有
3. 简单的代码一看都懂，复杂的代码没有注释、文档、流程图等确定真的可以自解释吗？

[ws52001]

理论上，开源的代码注释比较多，因为确实是想别人理解更多一点。。商业项目代码，无非就是加个码农名和更新时间，了不得加个更新目的。。

[dqzcwxb]

@elintwenty #34 你把问题说清了,很多人都是不在一个频道各说各的

[libook]

好的代码是能让人读出智慧的，不是单纯遵循某种硬规则的。

沟通的时候要讲究控制信息密度，信息太少无法准确传达，信息太多又难以让人提炼需要的部分，代码注释也一样。

[encro]

代码解析 how ，
注释解析 why 。

理解这句你就什么问题都解决了。

[skys215]

如果注释是拿来生成文档的，那当然是越多越好吧
不是的话，代码应该能够自表达。对于不符合常理或特殊情况才用注释解释
自表达代码： https://book.douban.com/subject/24858418/

[SeanGeek]

@wherewhale 不要动不动就“国内”