名字应该是非形式的、简练的、容易记忆的，如果可能的话，最好是能拼读的。
1.1 全局变量使用具有说明性的名字，局部变量用短名字。
1.2 保持一致性。相关的东西应该给以相关的名字，以说明它们的关系和差异。
1.3 函数采用动作性的名字。函数名应当用动作性的动词，后面可以跟着名字。
1.4 要准确。名字不仅是个标记，它还携带着给读程序人的信息。误用的名字可能引起奇怪的程序错误。
2. 表达式和语句
2.1 用缩行显示程序的结构。
2.2 使用表达式的自然形式。表达式应该写得你能大声念出来。含有否定运算的条件表达式比较难理解。
2.3 用加括号的方式排出二义性。
2.4 分解复杂的表达式。
eg: *x += (*xp=(2*k < (n-m) ? c[k+1] : d[k--]));
==>
if (2 * k < n - m)
*xp = c[k + 1];
else
*xp = d[k--];
*x += *xp;
2.5 要清晰。我们的目标应该是写出最清晰的代码，而不是最巧妙的代码。
2.6 担心副作用。
eg: C和C++对于副作用有关的执行顺序并没有明确定义，因此下面的多次赋值语句很可能产生错误的结果：
str[i++] = str[i++] = ' ';
这样写的意图是给str中随后的两个位置赋空格值，但实际效果却要依赖于 i 的更新时刻，很可能把str里的一个位置跳过去，也可能导致只对 i 实际更新一次，应该把它分成两个语句： str[i++] = ' '; str[i++] = ' ';
3. 一致性和习惯用法
3.1 使用一致的缩排和加括号风格。实际上，特定风格远没有一致地使用它们重要。
此外，如果你工作在一个不是自己写的程序上，请注意保留程序原有的风格，程序的一致性比你本人的习惯更重要。
3.2 为了一致性，使用习惯用法。
3.3 用else - if 表达多路选择。
4. 函数宏
人们使用函数宏的根本理由就是执行效率：宏可以避免函数调用的开销。在今天，函数宏的缺点远远超过它带来的好处。
4.1 避免函数宏。
C++里，内联函数更削减了函数宏的用武之地。Java中根本就没有宏这种东西。
函数宏最常见的一个严重问题是： 如果一个参数在定义中出现多次，它就可能被多次求值。
eg: #define isupper(c) ((c) >= 'A' && (c) <= 'Z')
如果isupper在下面的上下文中调用：
while (isupper(c = getchar()))
...
那么，每当遇到一个大于等于A的字符，程序就会将它丢掉，而下一个字符将被读入并去与Z做比较。重写上面的测试如下：
while ((c = getchar()) != EOF && isupper(c))
...
4.2 给宏的体和参数都加上括号。
宏是通过文本替换方式实现的：定义体里的参数被调用的实际参数替换，得到的结果再作为文本去替换原来的调用段。
eg: 表达式： 1 / square(x)
如果square定义为： #define square(x) (x)*(x) 则表达式展开成： 1 / (x) * (x)
正确定义： #define square(x) ((x)*(x))
即使是在宏定义里完全加上括号，也不可能解决前面所说的多次求值的问题。所以，如果一个操作比较复杂，或者它很具一般性，值得包装起来，那么还是应该使用函数。C++提供的内联函数既避免了语法方面的麻烦，而且又可得到宏能够提供的执行效率，很适合定义那些设置或提供一个值的短小函数。
5. 神秘的数
神秘的数包括各种常数、数组的大小、字符位置、变换因子以及程序中出现的其他以文字形式写出的数值。
5.1 给神秘的数起个名字。
作为一个指导原则，除了0和1之位，程序里出现的任何数大概都可以算是神秘的书，它们应该有自己的名字。
5.2 把数定义为常数，不要定义为宏。
使用宏编程是一种很危险的方式，因为宏会在背地里改变程序的词法结构。
C++里任何类型都可使用const声明的常数： const int MAXROW = 24;
Java中可以使用final声明： static final int MAXROW = 24;
C语言里也有const值，但是它们不能用作数组的界。这样，enum就是C中唯一可用的选择了。
5.3 使用字符形式的常量，不要用整数。
eg: if ( c >= 65 && c <= 90) 这种写法完全依赖于特殊的字符表示方式。写成下面这样会更好些:
if ( c >= 'A' && c <= 'Z')
如果在某个字符集里的字母编码不是连续的，或者其中还夹有其他字母，那么这种描述的效果就是错误的。最好是直接使用库函数。
5.4 利用语言去计算对象的大小。
不要对任何数据类型使用显示写出来的大小。
eg: sizeof(array[0])
#define NELEMS(array) (sizeof(array) / sizeof(array[0]))
6. 注释
注释是帮组程序读者的一种手段。但是，如果在注释中只说明代码本身已经讲明的事情，或者与代码矛盾，或是以精心编排的形式干扰读者，那么它们就帮了倒忙。最好的注释是简洁地点明程序的突出特征，或是提供一种概观，帮助别人理解程序。
6.1 不要大谈明显的东西。
注释应该提供那些不能一下子从代码中看到的东西，或者把那些散布在许多代码里的信息收集到一起。
6.2 给函数和全局数据加注释。
对于函数、全局变量、常数定义、结构和类的域等，以及任何其他加上简短说明就能够帮助理解的内容，都应该为之提供注释。
6.3 不要注释差的代码，重写它。
应该注释所有不寻常的或者可能迷惑人的内容。但是如果注释的长度超过了代码本身，可能就说明这个代码应该修改了。
6.4 不要与代码矛盾。
许多注释在写的时候和代码是一致的。但是后来由于修正错误，程序改变了，可是注释还保持着原来的样子，从而导致注释与代码的脱机。
注释不仅需要与代码保持一致，更应该支持它。
6.5 澄清情况，不要添乱。
注释应该在困难的地方尽量帮助读者，而不是给他们设置障碍。
我们应该尽可能地把代码写得容易理解。这方面做的越好，需要写的注释就越少。
程序设计的风格：具有说明性的名字、清晰的表达式、直接了当的控制流、可读的代码和注释，以及在追求这些内容时一致地使用某些规则和惯用法的重要性。
好的风格应该成为一种习惯。
最新评论