Ｃ＋＋／Ｃ提高编程质量的一些规则（1）

规则一：为了防止头文件被重复引用，应当用ifndef/define/endif结构产生预处理块。

规则二：用 #include <filename.h> 格式来引用标准库的头文件（编译器将从标准库目录开始搜索）。

规则三：用 #include “filename.h” 格式来引用非标准库的头文件（编译器将从用户的工作目录开始搜索）。

规则四：头文件中只存放“声明”而不存放“定义”.在C++语法中，类的成员函数可以在声明的同时被定义，并且自动成为内联函数。这虽然会带来书写上的方便，但却造成了风格不一致，弊大于利。建议将成员函数的定义与声明分开，不论该函数体有多么小。

规则五：不提倡使用全局变量，尽量不要在头文件中出现象extern int value 这类声明。

规则六：如果一个软件的头文件数目比较多（如超过十个），通常应将头文件和定义文件分别保存于不同的目录，以便
于维护。

规则七：如果某些头文件是私有的，它不会被用户的程序直接引用，则没有必要公开其“声明”。为了加强信息隐藏，
这些私有的头文件可以和定义文件存放于同一个目录。

规则八：在每个类声明之后、每个函数定义结束之后都要加空行。

规则九：在一个函数体内，逻揖上密切相关的语句之间不加空行，其它地方应加空行分隔。

规则十：一行代码只做一件事情，如只定义一个变量，或只写一条语句。这样的代码容易阅读，并且方便于写注释。

规则十一：if、for、while、do等语句自占一行，执行语句不得紧跟其后。不论执行语句有多少都要加{}。这样可以防止书写失误。

规则十二：尽可能在定义变量的同时初始化该变量（就近原则）如果变量的引用处和其定义处相隔比较远，变量的初始化很容易被忘记。如果引用了未被初始化的变量，可能会导致程序错误。

规则十三：关键字之后要留空格。象const、virtual、inline、case等关键字之后至少要留一个空格，否则无法辨析关键字。象if、for、while等关键字之后应留一个空格再跟左括号‘（’，以突出关键字。

规则十四：函数名之后不要留空格，紧跟左括号‘（’，以与关键字区别。

规则十五：‘（’向后紧跟，‘）’、‘，’、‘;’向前紧跟，紧跟处不留空格。

规则十六：‘，’之后要留空格，如Function(x, y, z)。如果‘;’不是一行的结束符号，其后要留空格，

如for(initialization; condition; update)。

规则十七：赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符，如“=”、“+=”，“>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<”,“^”等二元操作符的前后应当加空格。

规则十八：一元操作符如“!”、“~”、“++”、“--”、“&”（地址运算符）等前后不加空格。

规则十九：象“［］”、“.”、“->”这类操作符前后不加空格。

规则二十：程序的分界符‘{’和‘}’应独占一行并且位于同一列，同时与引用它们的语句左对齐。

规则二十一：}之内的代码块在‘{’右边数格处左对齐。

规则二十二：代码行最大长度宜控制在70至80个字符以内。代码行不要过长，否则眼睛看不过来，也不便于打印。

规则二十二：长表达式要在低优先级操作符处拆分成新行，操作符放在新行之首（以便突出操作符）。拆分出的新行要进行适当的缩进，使排版整齐，语句可读。

规则二十三：应当将修饰符 * 和 ＆ 紧靠变量名。

规则二十四：注释是对代码的“提示”，而不是文档。程序中的注释不可喧宾夺主，注释太多了会让人眼花缭乱。注释的花样要少。

规则二十五：如果代码本来就是清楚的，则不必加注释。否则多此一举，令人厌烦。

规则二十六：边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。不再有用的注释要删除。

规则二十七：注释应当准确、易懂，防止注释有二义性。错误的注释不但无益反而有害。

规则二十八：尽量避免在注释中使用缩写，特别是不常用缩写。

规则二十九：注释的位置应与被描述的代码相邻，可以放在代码的上方或右方，不可放在下方。

规则三十：当代码比较长，特别是有多重嵌套时，应当在一些段落的结束处加注释，便于阅读。

规则三十一：标识符应当直观且可以拼读，可望文知意，不必进行“解码”。标识符最好采用英文单词或其组合，便于记忆和阅读。切忌使用汉语拼音来命名。程序中的英文单词一般不会太复杂，用词应当准确。例如不要CurrentValue写成NowValue。

规则三十二：标识符的长度应当符合“min-length && max-information”原则。

规则三十三：命名规则尽量与所采用的操作系统或开发工具的风格保持一致。例如Windows应用程序的标识符通常采用“大小写”混排的方式，如AddChild。而Unix应用程序的标识符通常采用“小写加下划线”的方式，如add_child。别把这两类风格混在一起用。
规则三十四：程序中不要出现仅靠大小写区分的相似的标识符。

规则三十五：程序中不要出现标识符完全相同的局部变量和全局变量，尽管两者的作用域不同而不会发生语法错误，但会使人误解。

规则三十六：变量的名字应当使用“名词”或者“形容词＋名词”。

规则三十七：全局函数的名字应当使用“动词”或者“动词＋名词”（动宾词组）。类的成员函数应当只使用“动词”，被省略掉的名词就是对象本身。

规则三十八：用正确的反义词组命名具有互斥意义的变量或相反动作的函数等。

规则三十九：尽量避免名字中出现数字编号，如Value1,Value2等，除非逻辑上的确需要编号。这是为了防止程序员偷懒，不肯为命名动脑筋而导致产生无意义的名字（因为用数字编号最省事）。

规则四十：类名和函数名用大写字母开头的单词组合而成。

规则四十一：变量和参数用小写字母开头的单词组合而成。

规则四十二：常量全用大写的字母，用下划线分割单词。

规则四十三：静态变量加前缀s_（表示static）。

规则四十四：如果不得已需要全局变量，则使全局变量加前缀g_（表示global）。

规则四十五：类的数据成员加前缀m_（表示member），这样可以避免数据成员与成员函数的参数同名。

规则四十六：为了防止某一软件库中的一些标识符和其它软件库中的冲突，可以为各种标识符加上能反映软件性质的前缀。例如三维图形标准OpenGL的所有库函数均以gl开头，所有常量（或宏定义）均以GL开头。

规则四十七：如果代码行中的运算符比较多，用括号确定表达式的操作顺序，避免使用默认的优先级。

规则四十八：不要编写太复杂的复合表达式。不要有多用途的复合表达式。不要把程序中的复合表达式与“真正的数学表达式”混淆。

规则四十九：不可将布尔变量直接与TRUE、FALSE或者1、0进行比较。应当将整型变量用“==”或“！=”直接与0比较。

规则五十：不可将浮点变量用“==”或“！=”与任何数字比较。千万要留意，无论是float还是double类型的变量，都有精度限制。所以一定要避免将浮点变量用“==”或“！=”与数字比较，应该设法转化成“>=”或“<=”形式。假设浮点变量的名字为x，应当将if (x == 0.0) // 隐含错误的比较转化为if ((x>=-EPSINON) && (x<=EPSINON))其中EPSINON是允许的误差（即精度）。应当将指针变量用“==”或“！=”与NULL比较。