在以前一些关于代码注释的文章中，我发现，你不需要的注释才是最好的注释。不要急着批判，请允许我阐述一下。首先代码应该尽量地简洁，尽可能地做到不需要依赖注释就可以理解。只有那些真的没法更易于理解的代码，才需要我们添加注释。

　　有一本非常经典的书叫《Structure and Interpretation of Computer Programs》（《电脑程序的结构和编译》），最初发表于1985年，在序言中就表明其观点：

　　程序必须能便于我们阅读，让机器执行只是附带的。

　　Knuth也在他1984年发表的经典论文《Literate Programming》（《文学编程》）中秉持了类似的观点：

　　我们应该转变传统的思维，程序不再是告诉计算机做什么的指令，而是向人类描述如何让计算机做事情的文字，编程像写文章一样。

　　文学编程关注的主要是展现精致的风格。程序员应该像作家一样，认真地选择变量名，并解释每个变量的意思，努力写出易于人脑理解的程序。

　　如果你写出来的代码，既能被其他程序员理解又能成功编译，那么需要添加注释的地方肯定就不会很多。关于使用注释作为辅助工具，下面就是一个颇具代表意义的例子：

　　这段代码取自一个已经使用多年、闭源了的系统。

1. float _x = abs(x - deviceInfo->position.x) / scale; 
2. int directionCode; 
3. if (0 < _x & x != deviceInfo->position.x) { 
4.     if (0 > x - deviceInfo->position.x) { 
5.         directionCode = 0x04 /*left*/; 
6.     } else if (0 < x - deviceInfo->position.x) { 
7.         directionCode = 0x02 /*right*/; 
8.     } 
9. } 

　　上面的代码等同于下面的代码，但是下面的代码可读性更高。

1. static const int DIRECTIONCODE_RIGHT = 0x02; 
2.  
3. static const int DIRECTIONCODE_LEFT = 0x04; 
4.  
5. static const int DIRECTIONCODE_NONE = 0x00; 
6.  
7. int oldX = deviceInfo->position.x; 
8.  
9. int directionCode = (x > oldX) ? DIRECTIONCODE_RIGHT : (x > oldX) ? DIRECTIONCODE_LEFT : DIRECTIONCODE_NONE; 

　　需要注意的是，注释的越多并不意味着代码的理解性更强。当然在本案例中并没有涉及到这一点。上面的注释——如果你注意到的话——使得代码更加显得凌乱不堪。有时候，注释得越精简代码的可读性才越高。特别是在你必须更换使用其他符号名的情况下。

　　虽然我们能无限次地重构和精简代码以避免写繁冗的注释，但是表述自己的思考过程的方式却是有局限性的。

　　无论最后你呈现的代码是有多么的简洁和清楚，代码也不可能完全自文档化。但是代码永远也不可能取缔注释的存在。正如Jef Raskin所说：

　　[代码]无法解释如此写程序以及选择该方法的原因。从[代码]上我们也看不出选择某些替代方法的理由。例如：

1. /* A binary search turned out to be slower than the Boyer-Moore algorithm for the data sets of interest, thus we have used the more complex, but faster method even though this problem does not at first seem amenable to a string search technique. */ 

　　在A开发人员看来完全显而易见的东西，可能在B眼里完全就像雾里看花一样。所以我们在写注释的时候，也要考虑到这一点：

　　下面这个可能你一清二楚

1. $string = join(‘‘,reverse(split(‘‘,$string))); 

　　反转字符串，但是要如何才能插入到

1. # Reverse the string 

　　Perl文件中呢？

　　的确，这一点都不难。归根究底，代码只会告诉你程序是如何工作的，但是注释则能说明工作的原因。所以，下次你写代码的时候，不妨在这两个方面给你的同事做个榜样。

代码是灵魂，注释是心声