程序设计实践-阅读笔记（一）

有一段时间未读什么书了，周末两天于是拿起程序设计实践大概翻了一遍，以下便是个人总结第一章的主要的内容。

第一章：风格

1.1名字

　　全局变量使用具有说明性的名字，局部变量使用短名字。 命名约定能使自己的代码更容易理解，对别人写的代码也是一样。这些约定也使人在写代码时更容易决定事物的命名。

　　保持一致性。相关的东西应该给以相关的名字，以说明它们的关系和差异。

　　函数采用动作性的名字。函数名应当采用动作性的动词，后面可以跟着名词。

　　要准确。名字不仅是个标记，它还携带着给读程序人的信息。误用的名字可能会引起奇怪的程序错误。

1.2表达式和语句

　　用缩行显示程序的结构。采用一种一致的缩行风格，是使程序呈现出结构清晰的最省力的方法。

　　使用表达式的自然形式。表达式应该写的你能够大声念出来。

　　用加括号的方式排出二义性。括号表示分组，即使有时候并不必要，加了括号也可能把意图表示得更清楚。

　　分解复杂的表达式，要清晰。因为我们的目标应该是写出最清晰的代码，而不是最巧妙的代码。有些结构似乎总是要引诱人们去滥用它们。运算符?:大概属于这一类。

　　当心副作用。不仅增量和减量操作有副作用，I/O也是一种附带地下活动的操作。

　1.3一致性和习惯用法　

　　使用一致的缩排和加括号的风格。

　　为了一致性，使用习惯用法。一致性的使用习惯用法还有另一个优点，那就是使非标准的循环很容易被注意到。绝不要使用函数gets，因为你没办法限制它由输入那儿读入内容的数量。这常常会导致一个安全性问题。

　　用else-if表达多路选择。一系列嵌套的if语句通畅是说明了一段粗劣笨拙的代码。

　1.4函数宏

　　避免函数宏。老的程序员中有一种倾向，就是把很短的执行频繁的计算写成宏，而不是定义成函数。人们这样做的最根本的理由就是执行效率，宏可以避免函数调用的开销。函数宏最常见的一个严重问题是：如果一个参数在定义中出现多次，它就可能被多次求值。如果调用时的实际参数带有副作用，结果就会产生一个难以捉摸的错误。C语言标准是仔细写出来的，它允许将isupper及类似函数定义为宏，但要求保证他们的参数只求值一次。直接使用ctype提供的函数总比自己实现它们更好。有时多次求值带来的是执行效率的问题，而不是真正的错误。

　　给宏体和参数都加上括号。宏是通过文本替换方式实现的，定义体里的参数被调用的实际参数替换，得到的结果再作为文本去替换原来的调用段。

1.5神秘的数

　　神秘的数包括各种常数、数组的大小、字符位置、变换因子以及程序中出现的其他以文字形式写出的数值。

　　给神秘的数起个名字。

　　把数定义为常数，不要定义为宏。

　　使用字符形式的常量，不要用整数。

　　利用语言去计算对象的大小。不要对任何数据类型使用显式写出来的大小。

1.6注释

　　注释是帮助程序读者的一种手段。最好的注释是简洁的点名程序的突出特征，或是提供一种概观，帮助别人理解程序。

　　不要大谈明显的东西。注释应该提供那些不能一下子从代码中看到的东西，或者把那些散布在许多代码里的信息收集到一起。当某些难以捉摸的事情出现时，注释可以帮助澄清情况。

　　给函数和全局数据加注释。任何加上简短的说明就能够帮助理解的内容，我们都应该为之提供注释。放在每个函数前面的注释可以成为帮人读懂程序的台阶。如果函数代码不太长，在这里写一行注释就足够了。

　　不要注释差的代码，重写它。如果注释的长度超过了代码本身，可能就说明这个代码应该修改了。

　　注释不要与代码矛盾。注释不仅需要与代码保持一致，更应该能够支持它。

　　澄清情况，不要添乱。注释应该在困难的地方尽量帮助读者，而不是给他们设置障碍。应该尽可能的把代码写的容易理解。在这方面你做的越好，需要写的注释就越少。

总结：好的风格应该成为一种习惯。如果你在开始写代码时就关心风格问题，如果你花时间去审视和改进它，你将逐渐养成一种好的编程习惯。一旦这种习惯变成自动的东西，你的潜意识就会帮你照料许多细节问题。甚至你在工作压力写出的代码也会更好。