高质量C++/C 编程指南，v 1.0
2.5 长行拆分
? 【规则2-5-1】代码行最大长度宜控制在70至80个字符以内。代码行不要过长，否
则眼睛看不过来，也不便于打印。
? 【规则2-5-2】长表达式要在低优先级操作符处拆分成新行，操作符放在新行之首（以
便突出操作符）。拆分出的新行要进行适当的缩进，使排版整齐，语句可读。 ?
if ((very_longer_variable1 >= very_longer_variable12) && (very_longer_variable3 <= very_longer_variable14) && (very_longer_variable5 <= very_longer_variable16)) { dosomething(); } virtual CMatrix CMultiplyMatrix (CMatrix leftMatrix, CMatrix rightMatrix); for (very_longer_initialization; { } 示例2-5 长行的拆分
very_longer_condition; very_longer_update) dosomething(); 2.6 修饰符的位置
修饰符 * 和 ＆ 应该靠近数据类型还是该靠近变量名，是个有争议的活题。 若将修饰符 * 靠近数据类型，例如：int* x; 从语义上讲此写法比较直观，即x是int 类型的指针。
上述写法的弊端是容易引起误解，例如：int* x, y; 此处y容易被误解为指针变量。虽然将x和y分行定义可以避免误解，但并不是人人都愿意这样做。
? 【规则2-6-1】应当将修饰符 * 和 ＆ 紧靠变量名
例如：
char *name;
int *x, y;
// 此处y不会被误解为指针
2001
Page 17 of 98
高质量C++/C 编程指南，v 1.0
2.7 注释
C语言的注释符为“/*…*/”。C++语言中，程序块的注释常采用“/*…*/”，行注释一般采用“//…”。注释通常用于： （1）版本、版权声明； （2）函数接口说明；
（3）重要的代码行或段落提示。
虽然注释有助于理解代码，但注意不可过多地使用注释。参见示例2-6。
? 【规则2-7-1】注释是对代码的“提示”，而不是文档。程序中的注释不可喧宾夺主，
注释太多了会让人眼花缭乱。注释的花样要少。
? 【规则2-7-2】如果代码本来就是清楚的，则不必加注释。否则多此一举，令人厌烦。
例如
i++; // i 加 1，多余的注释
? 【规则2-7-3】边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码
的一致性。不再有用的注释要删除。
? 【规则2-7-4】注释应当准确、易懂，防止注释有二义性。错误的注释不但无益反而
有害。
? 【规则2-7-5】尽量避免在注释中使用缩写，特别是不常用缩写。
? 【规则2-7-6】注释的位置应与被描述的代码相邻，可以放在代码的上方或右方，不
可放在下方。
? 【规则2-7-8】当代码比较长，特别是有多重嵌套时，应当在一些段落的结束处加注
释，便于阅读。 /* * 函数介绍： * 输入参数： * 输出参数： * 返回值 ： */ void Function(float x, float y, float z) { … } 示例2-6 程序的注释
if (…) { … while (…) { … } // end of while … } // end of if
2001
Page 18 of 98
高质量C++/C 编程指南，v 1.0
2.8 类的版式
类可以将数据和函数封装在一起，其中函数表示了类的行为（或称服务）。类提供关键字public、protected和private，分别用于声明哪些数据和函数是公有的、受保护的或者是私有的。这样可以达到信息隐藏的目的，即让类仅仅公开必须要让外界知道的内容，而隐藏其它一切内容。我们不可以滥用类的封装功能，不要把它当成火锅，什么东西都往里扔。
类的版式主要有两种方式：
（1）将private类型的数据写在前面，而将public类型的函数写在后面，如示例8-3（a）。采用这种版式的程序员主张类的设计“以数据为中心”，重点关注类的内部结构。 （2）将public类型的函数写在前面，而将private类型的数据写在后面，如示例8.3（b）采用这种版式的程序员主张类的设计“以行为为中心”，重点关注的是类应该提供什么样的接口（或服务）。
很多C++教课书受到Biarne Stroustrup第一本著作的影响，不知不觉地采用了“以数据为中心”的书写方式，并不见得有多少道理。
我建议读者采用“以行为为中心”的书写方式，即首先考虑类应该提供什么样的函数。这是很多人的经验——“这样做不仅让自己在设计类时思路清晰，而且方便别人阅读。因为用户最关心的是接口，谁愿意先看到一堆私有数据成员！”
class A { private: int i, j; float x, y; … public: void Func1(void); void Func2(void); … } 示例8.3(a) 以数据为中心版式
class A { public: void Func1(void); void Func2(void); … private: int i, j; float x, y; … } 示例8.3(b) 以行为为中心的版式
2001
Page 19 of 98
高质量C++/C 编程指南，v 1.0
第3章 命名规则
比较著名的命名规则当推Microsoft公司的“匈牙利”法，该命名规则的主要思想是“在变量和函数名中加入前缀以增进人们对程序的理解”。例如所有的字符变量均以ch为前缀，若是指针变量则追加前缀p。如果一个变量由ppch开头，则表明它是指向字符指针的指针。
“匈牙利”法最大的缺点是烦琐，例如 int i, j, k; float x, y, z;
倘若采用“匈牙利”命名规则，则应当写成
int iI, iJ, ik; // 前缀 i表示int类型 float fX, fY, fZ; // 前缀 f表示float类型 如此烦琐的程序会让绝大多数程序员无法忍受。
据考察，没有一种命名规则可以让所有的程序员赞同，程序设计教科书一般都不指定命名规则。命名规则对软件产品而言并不是“成败悠关”的事，我们不要化太多精力试图发明世界上最好的命名规则，而应当制定一种令大多数项目成员满意的命名规则，并在项目中贯彻实施。
3.1 共性规则
? 【规则3-1-1】标识符应当直观且可以拼读，可望文知意，不必进行“解码”。
标识符最好采用英文单词或其组合，便于记忆和阅读。切忌使用汉语拼音来命名。程序中的英文单词一般不会太复杂，用词应当准确。例如不要把CurrentValue写成NowValue。
? 【规则3-1-2】标识符的长度应当符合“min-length && max-information”原则。
几十年前老ANSI C规定名字不准超过6个字符，现今的C++/C不再有此限制。一般来说，长名字能更好地表达含义，所以函数名、变量名、类名长达十几个字符不足为怪。那么名字是否越长约好？不见得! 例如变量名maxval就比maxValueUntilOverflow好用。单字符的名字也是有用的，常见的如i,j,k,m,n,x,y,z等，它们通常可用作函数内的局部变量。
? 【规则3-1-3】命名规则尽量与所采用的操作系统或开发工具的风格保持一致。
例如Windows应用程序的标识符通常采用“大小写”混排的方式，如AddChild。而Unix应用程序的标识符通常采用“小写加下划线”的方式，如add_child。别把这两类风
本节论述的共性规则是被大多数程序员采纳的，我们应当在遵循这些共性规则的前
提下，再扩充特定的规则，如3.2节。
2001
Page 20 of 98
