版权声明:本文为博主原创文章,未经博主允许不得转载。
整理自知乎上我的一次回答。http://www.zhihu.com/question/20594192
我的观点,只写说明性注释,不写功能性注释。也就是说,注释Why,而不是How和What。
类和函数多写 文档注释 ,多少行无所谓,写在最前面,只要你是注释的Why。
函数内部,尽量少写注释。如果你的代码需要写注释来说明他的功能,那么这段代码就需要 重构 ,最简单的方法,最简单的方法: 提取函数 。这样的好处是,函数名就是注释。一个错误的观点就是 注释是给人看的,程序是给电脑看的 。其实,程序是给人看的,凑巧的是,它居然可以在电脑里运行。
《 重构:改善既有代码的设计 》一书写道:

每当感觉需要以注释来说明点什么的时候,我们就把需要说明的东西写进一个独立函数中,并以其用途(而非实现手法)命名。每次我给别人讲解「选择排序」、「插入排序时」,他们都觉得太难了,而且几乎每本数据结构教科书都是写了一堆代码和注释,这丝毫没有降低这个算法的难度。
如果不写注释,而写成函数呢?
伪代码:
array_ordered = []
loop_all_element(array, function(i){
el = select(array[i+1, array.length])
push(array_ordered, el)
......
})
- 构建一个有序数组,初始为空,(ps:空集都是有序集)。
- 循环整个数组,进行如下操作:
- 从数组剩下的元素里面选择最小的(或最大的)
- 将最小元素放在有序数组的最后面(或者最前面)
插入排序呢?大同小异,我就不详细写了。

所以,文档注释,多少无所谓。函数内、类内注释,能不写,就不写。
相关阅读:千万要避免的五种程序注释方式
你是否有过复查程序时发现有些注释毫无用处?程序注释是为了提高代码的可读性,为了让原作者以外的其他开发人员更容易理解这段程序。
我把这些让人郁闷的注释方式归为了五类,同时把写出这些注释的程序员也归为了五类。我希望读了这篇文章后你感觉自己不属于其中的任何一种类型。如果你有兴趣的话可以读一下另外一篇文章 五种程序员(英文),和这篇讲到的五种程序员对比一下。
1. 高傲的程序员
这种程序员是如此的欣赏自己的程序,以至于不得不在每行代码上都署上自己的大名。应该让版本控制系统来提供程序变更的信息,他这样做一眼看去并不能说明谁对这行代码负责。
2. 过时的程序员
如果一段程序不再有用(比如废弃了),那就删了它吧——不要被几行没用的注释搞的程序混乱不堪。即使你可能以后重用这段代码,你也可以使用版本控制系统,用它把你的程序恢复到以前的样子。
3. 天真的程序员
基本的编程语法规则我们大家都知道——我们不需要“编程入门”。你不需要浪费时间来解释一个显而易见的东西,我们更希望知道的是你的程序功能——那是浪费空间了。
4. 传奇的程序员
如果你不得不在注释里写明需求,那也不要提到人名。销售员Jim很可能在公司里不再是销售。而且大多数读到这段注释的程序员未必都知道Jim是谁。你描述的是实际情况但跟我们的内容不相干,所以就省掉吧。
5. 未来程序员
这种注释是一种集大成者,它包含了上面所说的注释的所有问题。TODO注释在一个项目最初的开发阶段是非常有用的,但这个注释看起来是在好几年前的产品程序里的——它证明了程序有问题。如果程序有问题需要解决,马上解决,不要拖到日后再解决。
如果你不幸是生成这些类型注释的人,或者你想学习注释用法的最佳实践,我推荐你阅读Steve McConnell写的Code Complete(《代码大全》)。这是一本我建议程序员必读的书籍,优快云 地址 http://blog.youkuaiyun.com/justjavac/article/details/7865418。
https://i-blog.csdnimg.cn/blog_migrate/821f0957c1aa6777c25338214126729d.png