编码的艺术

我在本文中要谈的不是编码的技术实现，我所关注的是关于编码的风格的问题。我在编写了e速的编码规范之后，产生了要写一些关于程序编码风格的念头；因此，就有了以下的文章，这些仅仅是本人的想法，可能在文章中还有一些未尽如人意的地方，所以肯请大家能够给与谅解。
  　很多人在谈到编码的艺术时，总会说我的程序怎么怎么的厉害，功能多么的强大，好像什么事情都能完成一样；但是去运行他的程序，bug不断；连他自己都不知道错在了什么地方。打开他的程序一看，代码写的凌乱不堪；命名上不规范，为了偷懒和简便有些命名干脆就用一个字母或者其他的简单符号代替，甚至于有些代码连他自己也搞不清是干什么了，更不要说怎样让别人去修改了….本人编码也快4个年头了，像上述的例子遇见过不少，整个程序改动起来实在是头疼。
  　的确，一件好的艺术品不在于其功能是多么的完善，而在于别人欣赏起来是否有它内在的美和是否很容易就把它从杂货堆里一眼就能辨认出来；毕竟它是艺术品而非日用品。我们写程序也是同样，如果程序中的格式很随意，例如对数组做循环，一会儿采用下标变量从下到上的方式，一会儿又用从上到下的方式；对字符串一会儿用s t r c p y做复制，一会儿又用f o r循环做复制；等等。这些变化就会使人很难看清实际上到底是怎么回事了。
写好一个程序，当然需要使它符合语法规则、修正其中的错误和使它运行得足够快，但是实际应该做的远比这多得多。程序不仅需要给计算机读，也要给程序员读。一个写得好的程序比那些写得差的程序更容易读、更容易修改。经过了如何写好程序的训练，生产的代码更可能是正确的。

　　注释：注释是帮助程序读者的一种手段。但是，如果在注释中只说明代码本身已经讲明的事情，或者与代码矛盾，或是以精心编排的形式干扰读者，那么它们就是帮了倒忙。最好的注释是简洁地点明程序的突出特征，或是提供一种概观，帮助别人理解程序。在标注注释的同时，应该注意下面的问题：
　
　　不要大谈明显的东西。注释不要去说明明白白的事，比如i + +能够将i值加1等等。注释应该提供那些不能一下子从代码中看到的东西，或者把那些散布在许多代码里的信息收集到一起。当某些难以捉摸的事情出现时，注释可以帮助澄清情况。如果操作本身非常明了，重复谈论它们就是画蛇添足了；给函数和全局数据加注释。注释当然可以有价值。对于函数、全局变量、常数定义、结构和类的域等，以及任何其他加上简短说明就能够帮助理解的内容，我们都应该为之提供注释。全局变量常被分散使用在整个程序中的各个地方，写一个注释可以帮人记住它的意义，也可以作为参考。放在每个函数前面的注释可以成为帮人读懂程序的台阶。如果函数代码不太长，在这里写一行注释就足够了。有些代码原本非常复杂，可能是因为算法本身很复杂，或者是因为数据结构非常复杂。在这些情况下，用一段注释指明有关文献对读者也很有帮助。此外，说明做出某种决定的理由也很有价值。
  　职业程序员也常被要求注释他们的所有代码。但是，应该看到，盲目遵守这些规则的结果却可能是丢掉了注释的真谛。注释是一种工具，它的作用就是帮助读者理解程序中的某些部分，而这些部分的意义不容易通过代码本身直接看到。我们应该尽可能地把代码写得容易理解。在这方面你做得越好，需要写的注释就越少。好的代码需要的注释远远少于差的代码。
编码的风格：全局变量应该采用具有描述意义的名字，局部变量用短名字。函数采用动作性的名字。给神秘的数起个名字。现实中存在许多命名约定或者本地习惯。常见的比如：指针采用以p结尾的变量名，例如n o d e p；全局变量用大写开头的变量名，例如G l o b a l；常量用完全由大写字母拼写的变量名，如C O N S T A N T S等。命名约定能使自己的代码更容易理解，对别人写的代码也是一样。这些约定也使人在写代码时更容易决定事物的命名。对于长的程序，选择那些好的、具有说明性的、系统化的名字就更加重要。
　　
　　保持一致性。要准确。以缩行形式显示程序结构。使用表达式的自然形式。利用括号排除歧义。分解复杂的表达式。要清晰。当心副作用。使用一致的缩行和加括号风格。为了一致性，使用习惯用法。用else-if 处理多路选择。避免使用函数宏。给宏的体和参数都加上括号。这些都是很琐碎的事情，但却又是非常有价值的，就像保持书桌整洁能使你容易找到东西一样。与你的书桌不同的是，你的程序代码很可能还会被别人使用。
用缩行显示程序的结构。采用一种一致的缩行风格，是使程序呈现出结构清晰的最省力的方法。
　　用加括号的方式排除二义性。括号表示分组，即使有时并不必要，加了括号也可能把意图表示得更清楚。在混合使用互相无关的运算符时，多写几个括号是个好主意。C语言以及与之相关的语言存在很险恶的优先级问题，在这里很容易犯错误。例如，由于逻辑运算符的约束力比赋值运算符强，在大部分混合使用它们的表达式中，括号都是必需的。
利用语言去计算对象的大小。不要大谈明显的东西。给函数和全局数据加注释。不要注释不好的代码，应该重写。不要与代码矛盾。澄清情况，不要添乱。
界面的风格：隐蔽实现的细节。不要在用户背后搞小动作。在各处都用同样方式做同样的事。释放资源与分配资源应该在同一层次进行。在低层检查错误，在高层处理。只把异常用在异常的情况。

　　写良好的代码更容易阅读和理解，几乎可以保证其中的错误更少。进一步说，它们通常比那些马马虎虎地堆起来的、没有仔细推敲过的代码更短小。在这个拼命要把代码送出门、去赶上最后期限的时代，人们很容易把风格丢在一旁，让将来去管它们吧。但是，这很可能是一个代价非常昂贵的决定。上面的一些陈述性的言语充分的说明了，如果对好风格问题重视不够，程序中哪些方面可能出毛病。草率的代码是很坏的代码，它不仅难看、难读，而且经常崩溃。好风格应该成为一种习惯。如果你在开始写代码时就关心风格问题，如果你花时间去审视和改进它，你将会逐渐养成一种好的编程习惯。一旦这种习惯变成自动的东西，你的潜意识就会帮你照料许多细节问题，甚至你在工作压力下写出的代码也会更好