前言

“慎始如终，则无败事。”我们应以严谨认真、力求完美的态度对待编程这件事，养成良好的编程习惯和代码风格。

1. 头文件

每个 C++/C 程序通常分为两个文件。

一个文件用于保存程序的声明，称为头文件。C++/C 程序的头文件以“.h ”为后缀。

另一个文件用于保存程序的实现，称为定义文件。C 程序的定义文件以“.c ”为后缀；C++程序的定义文件通常以“.cpp ”为后缀（也有一些系统以“.cc ”或“.cxx）。

规定：

1. 为了防止头文件被重复引用，应当用ifndef/define/endif结构产生预处理模块。
2. 用#include <xxxxxx.h>格式来引用标准库的头文件（编译器将从标准库目录开始搜索）。
3. 用#include “xxxxxx.h”格式来引用非标准库的头文件（编译器将从用户的工作目录开始搜索）。

建议1：

• 头文件中只存放“声明”而不存放“定义”。

原因：

1. 在 C++ 语法中，类的成员函数可以在声明的同时被定义，并且自动成为内联函数。
2. 这虽然会带来书写上的方便，但却造成了风格不一致，弊大于利。

建议将成员函数的定义与声明分开，不论该函数体有多么小。

建议2：

• 不提倡使用全局变量，尽量不要在头文件中出现像extern int value 这类声明。

头文件的作用：

1. 通过头文件来调用库功能。在很多场合，源代码不便（或不准）向用户公布，只要向用户提供头文件和二进制的库即可。用户只需要按照头文件中的接口声明来调用库功能，而不必关心接口怎么实现的。编译器会从库中提取相应的代码。
2. 头文件能加强类型安全检查。如果某个接口被实现或被使用时，其方式与头文件中的声明不一致，编译器就会指出错误，这一简单的规则能大大减轻程序员调试、改错的负担。

2. 代码风格

1). 空行

空行起着分隔程序段落的作用。空行得体（不过多也不过少）将使程序的布局更加清晰。空行不会浪费内存，虽然打印含有空行的程序是会多消耗一些纸张，但是值得。

规定：

1. 在每个类声明之后、每个函数定义结束之后都要加空行。
2. 在一个函数体内，逻揖上密切相关的语句之间不加空行，其它地方应加空行分隔。

2). 代码行

规定：

1. 一行代码只做一件事情，如只定义一个变量，或只写一条语句。这样的代码容易阅读，并且方便于写注释。
2. if 、for 、while 、do 等语句自占一行，执行语句不得紧跟其后。不论执行语句有多少都要加{}，以防止书写失误。

建议：尽可能在定义变量的同时初始化该变量（就近原则）

原因：

1. 如果变量的引用处和其定义处相隔比较远，变量的初始化很容易被忘记。
2. 如果引用了未被初始化的变量，可能会导致程序错误。

int width;//定义变量width，但并未初始化
int height = 0;//定义并初始化变量height//强烈建议

上述建议可以减少隐患。

3). 代码行内的空格

规定：

1. 关键字之后要留空格。像const、virtual、inline、case等关键字之后至少要留一个空格，否则无法辨析关键字。像if、for、while等关键字之后应留一个空格再跟左括号’('，以突出关键字。
2. 函数名之后不要留空格，紧跟左括号’('，以与关键字区别。
3. 左括号’(‘向后紧跟，右括号’)‘、逗号’,‘、分号’;'向前紧跟，紧跟处不留空格。
4. 逗号’,'之后要留空格，如Function(x, y, z) 。如果分号’;'不是一行的结束符号，其后要留空格，如for ( initialization; condition; update)。
5. 赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符，如“= ”、“+= ” “>= ”、“<= ”、“+ ”、“* ”、“% ”、“&& ”、“|| ”、“<< ”, “^”等二元操作符的前后应当加空格。
6. 一元操作符如“! ”、“~ ”、“++ ”、“-- ”、“&”（地址运算符）等前后不加空格。
7. 像"[]“、”-“、”->"这类操作符前后不加空格。

建议：

• 对于表达式比较长的 for 语句和 if 语句，为了紧凑起见可以适当地去掉一些空格，如for (i=0; i<10; i++) 和if ((a<=b) && (c<=d))。

4). 对齐

规定：

1. 程序的分界符‘{ ’和‘}’应独占一行并且位于同一列，同时与引用它们的语句左对齐。
2. { } 之内的代码块在‘{’右边数格处左对齐。

5). 长行拆分

规定：

1. 代码行最大长度宜控制在 70 至 至 80 个字符以内。代码行不要过长，否则眼睛看不过来，也不便于打印。
2. 长表达式要在低优先级操作符处拆分成新行，操作符放在新行之首（以便突出操作符）。拆分出的新行要进行适当的缩进，使排版整齐，语句可读。

6). 修饰符的位置

修饰符 * 和 ＆ 应该靠近数据类型还是该靠近变量名，是个有争议的话题。

若将修饰符 * 靠近数据类型，例如：int* x; 即 从语义上讲此写法比较直观，即 x 是 int 类型的指针。

上述写法的弊端是容易引起误解，例如：==int* x, y;==此处 y 容易被误解为指针变量。虽然将 x 和 y 分行定义可以避免误解，但并不是人人都愿意这样做。

规定：

• 应当将修饰符 * 和 ＆ 紧靠变量名

char *name;
char *x,y;//此处 y 不会被误解为指针

7). 注释

C 语言的注释符为“/…/”。C++ 语言中，程序块的注释常采用“/…/”，行注释一般采用“//…”。

注释通常用于：

1. 版本、版权声明；
2. 函数接口说明；
3. 重要的代码行或段落提示；

虽然注释有助于理解代码，但注意不可过多地使用注释。

规定：

1. 注释是对代码的“提示”，而不是文档。程序中的注释不可喧宾夺主，注释太多了会让人眼花缭乱。注释的花样要少。
2. 如果代码本来就是清楚的，则不必加注释。否则多此一举，令人厌烦。i ++; / / i 加 1 ，多余的注释（初学者自用笔记随意，反正我是这么干的）
3. 边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。不再有用的注释要删除。
4. 注释应当准确、易懂，防止注释有二义性。错误的注释不但无益反而有害。
5. 尽量避免在注释中使用缩写，特别是不常用缩写。
6. 注释的位置应与被描述的代码相邻，可以放在代码的上方或右方，不可放在下方。
7. 当代码比较长，特别是有多重嵌套时，应当在一些段落的结束处加注释，便于阅读。

3. 命名规则

比较著名的命名规则当推 Microsoft 公司的“匈牙利”法，该命名规则的主要思想是“在变量和函数名中加入前缀以增进人们对程序的理解”。例如所有的字符变量均以ch 为前缀，若是指针变量则追加前缀 p 。如果一个变量由 ppch 开头，则表明它是指向字符指针的指针。

“匈牙利”法最大的缺点是烦琐，例如：

int i, j, k;
float x, y, z;

倘若采用“匈牙利”命名规则，则应当写成：

int il, ij, ik;//前缀 i 表示 int 类型
float fx, fy, fz;//前缀 f 表示 float 类型

如此烦琐的程序会让绝大多数程序员无法忍受。

据考察，没有一种命名规则可以让所有的程序员赞同，程序设计教科书一般都不指定命名规则。命名规则对软件产品而言并不是“成败悠关”的事，我们不要化太多精力试图发明世界上最好的命名规则，而应当制定一种令大多数项目成员满意的命名规则，并在项目中贯彻实施。

1). 共性规则

共性规则是被大多数程序员采纳的，我们应当在遵循这些共性规则的前提下，再扩充特定的规则，如：简单的 Windows 应用程序命名规则。

规定：

1. 标识符应当直观且可以拼读，可望文知意，不必进行“解码”。

标识符最好采用英文单词或其组合，便于记忆和阅读。切忌使用汉语拼音来命名。程序中的英文单词一般不会太复杂，用词应当准确。例如不要把CurrentValue写成NewValue。

2. 标识符的长度应当符合“ min-length && max-information ”原则。

几十年前老 ANSI C 规定名字不准超过 6 个字符，现今的 C++/ C不再有此限制。一般来说，长名字能更好地表达含义，所以函数名、变量名、类名长达十几个字符不足为怪。那么名字是否越长越好？不见得！ 例如变量名 maxval 就比 maxValueUntilOverflow 好用。单字符的名字也是有用的，常见的如 i , j , k, m, n, x, y, z 等，它们通常可用作函数内的局部变量。

3. 命名规则尽量与所采用的操作系统或开发工具的风格保持一致。

例如 Windows 应用程序的标识符通常采用“大小写”混排的方式，如 AddChild。而 Unix 应用程序的标识符通常采用“小写加下划线”的方式，如 add_child。别把这两类风格混在一起使用。

4. 程序中不要出现仅靠大小写区分的相似的标识符。

int x, X;//变量 x 和 X 容易混淆
void foo(int x);//函数 foo 与 FOO 容易混淆
void FOO(float x);

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

6. 变量的名字应当使用“名词”或者“形容词＋名词”。

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

DrawBox();//全局函数
box->Draw();//类的成员函数

8. 用正确的反义词组命名具有互斥意义的变量或相反动作的函数等。

int mianValue;
int maxValue;

int SetValue(...);
int GetValue(...);

建议：

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

2). 简单的 Windows 应用程序命名规则

对“匈牙利”命名规则做了合理的简化，下述的命名规则简单易用，比较适合于 Windows 应用软件的开发。

规定：

1. 类名和函数名用大写字母开头的单词组合而成。

class Node;//类名
class LeafNode;//类名
void Draw(void)//函数名
void SetValue(int value);//函数名

2. 变量和参数用小写字母开头的单词组合而成。

BOOL flag;
int darwMode;

3. 常量全用大写的字母，用下划线分割单词。

const int MAX = 100;
const int MAX_LENGTH = 100;

4. 静态变量加前缀 s_ （表示 static)。

void Init(…)
{
static int s_initValue; // 静态变量
…
}

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

int g_howManyPeople; // 全局变量
int g_howMuchMoney; // 全局变量

6. 类的数据成员加前缀 m_ （表示 member），这样可以避免数据成员与成员函数的参数同名。

voi d Obj ect : : Set Val ue( i nt wi dt h, i nt hei ght )
{
m_wi dt h = wi dt h;
m_hei ght = hei ght ;
}

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

4. 运算符和表达式

1). 运算符的优先级

C++/C 语言的运算符有数十个，运算符的优先级与结合律如表 4-1 所示。注意一元运算符 + - * 的优先级高于对应的二元运算符。

优先级按从高到低排序：

规定：

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

由于将上表熟记是比较困难的，为了防止产生歧义并提高可读性，应当用括号确定表达式的操作顺序。例如：

word = (high << 8) | low;
if ((a | b) && (a & c))

2). 复合表达式

如 a = b = c = 0 这样的表达式称为复合表达式。

允许复合表达式存在的理由是：

1. 书写简洁；
2. 可以提高编译效率。

但要防止滥用复合表达式。

规定：

1. 不要编写太复杂的复合表达式。

i = a >= b && c < d && c + f <= g + h ; / / 复合表达式过于复杂

2. 不要有多用途的复合表达式。

d = ( a = b + c) + r ;//该表达式既求 a 值又求 d 值。

//应该拆分为两个独立的语句：
a = b + c;
d = a + r ;

3. 不要把程序中的复合表达式与“真正的数学表达式”混淆。

i f ( a < b < c) / / a < b < c 是数学表达式而不是程序表达式

//并不表示：
i f ( ( a<b) && ( b<c) )

//而是成了令人费解的：
i f ( ( a<b) <c )

总结

本文是仓促之下做的笔记，如有谬误之处恳请指正，万分感谢。