检测的标准其实很简单

如果你是一个solo工作者:

你找一个一个月前写的代码,去看,看得懂,OK,可以继续不写注释

如果你是一个team工作者:

把你的代码给同事看,看得懂,OK,可以继续不写注释

Controller曾一般会写,声明下干什么用的,service和dao层一般不写

嗯,我们公司 Style Guide 说原则上不允许注释。

如果你发现你的代码要写注释才能看懂,请重构代码,把逻辑抽象成方法,并且起一个一看就懂的名字。有东西实在想要解释,就写在 git commit message 里,别人发现代码难懂的时候 git blame 一下就知道谁写的这段代码,为什么写,甚至和这段代码一起改了哪些东西都一目了然。

写注释的缺点是容易有人改了代码而忘了改注释,造成误导。

我们是用 Ruby 的,开新方法很平常。有些对性能比较注重的领域,用 C 或 Java 的话,可能不适合这样做。

要看具体情况。我工地的工作经常牵涉到几个坐标系之间的计算,参数注释写清楚,大家都方便。或者你平时用的第三方开源库,如果没有注释都能明白么?

1楼 @tinyfool 一直坚持写无注释代码,现在也习惯了,把该注释的东西,都写进代码里了。

3楼 @SteveLTN 正解,把需要注释的东西,都写进代码,如果需要注释才能理解的代码,果断重构。

到现在一行注释都没有写 我坚信 代码是个人看的 不需要注释

我也是一个人复杂iOS app开发,从来没写过注释 😁

注释是必须的。如果各种不行还好,可以直接炒掉。最麻烦的就是,又基本达标的,要炒掉吧,又不服。

不但要注释,只要是出X.X.X的版本都必须文档跟上。注释和文档都必须正规,不能按自己风格写。

我们公司以前的代码也没有注释,前提是你写那东西得别人能看懂啊?所以现在还是要求有注释。我自己的注释重点不是代码内部,主要是模块设计的说明和模块接口参数说明。