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

像 Spring 这种库是让其它人调用的，一般不会去看代码再去使用，这种要写，不过其实这个写的不是注释，而是文档，不然为什么叫 javadoc 。

文档是给用户看的，注释是给自己或自己组里人看的。

java 那种源码里很多是为了生成 doc 的

尽量还是代码简短易懂吧, 不要瞎搞骚操作, 我们有个前同事, 用 GO 写代码很喜欢 用 interface 然后再做类型推断, 还喜欢传闭包函数, 就是他写的代码, 很多我不加断点我都不知道跑到哪了. 我还算好的, 有的同事直接看懂不

对于一些复杂的业务逻辑, 没法简化的, 我现在都是把公式写在相关代码前面

最近刚写了一段儿感觉要被同事打的注释，我就是想解释下下面那个参数什么意思。😂
https://s1.ax1x.com/2022/05/30/XldcLt.png

多写注释可以，不过有的人(我同事)改了代码不改注释的，非常离谱

这是对其他人的要求，放自己身上就总觉得不合适

再次尝试贴图

看什么项目，开源的自然是越多越好；公司项目也要有标准；个人项目就无所谓了，自己懂就行

注释不算 KPI ，代码才是 KPI 。如果想要好的注释，那把注释加入 KPI 不就行了。

记得看过一句话，冗长复杂的代码的注释，就好像是给后面接手的人一个道歉信

代码是进行时，注释是过去时。

注释容易出现代码变更，但是注释没跟着改的现象。

第一次看《 clean code 》这句话就有很深的印象。

“好的代码不需要注释” 这句话我都快听腻了，然而很多人写的代码并不好

实际上 5 楼的注释都是文档, 而真正的注释是代码本身. 实际上 Jdk 中从接口到 abstract class 到实现类都符合这样的表现: 注释越来越少, 代码越来越多. 总不能说接口是好代码, 而实现类不是吧.

写注释的绩效比写代码的绩效多吗。。。

评价代码好坏是个复杂问题。有时候，不同时代，不同价值观都可能导致评价结果出现较大偏差。

统计注释 /代码比是个简单方案，很简单就可以通过工具来实现此目的。

通过一个简单方案来粗暴解决一个复杂问题，这种悲剧大家还看的少了？眼前的例子还不够么？

多看看大的开源库的代码就知道了，应该没人会觉得自己的代码写的比几万 star 的项目的代码更好了吧？

业务代码,简练,高密度信息的注释表达清楚为什么这么做还是有必要的, 靠代码猜逻辑还是很痛苦的. 废话注释就免了, 代码有足够的抽象, 良好的命名, 就能让人一看就知道做什么了.

最好是用一句话就说明白这段代码的作用，而不是废话连篇给你复制半本 txt 电子书！

深表认同 方法名就是注释

大部分语言的标准库里最复杂的算法 -- timsort. 目测代码: 注释 = 10 : 1

https://svn.python.org/projects/python/trunk/Objects/listobject.c