版式虽然不会影响程序的功能，但会影响可读性。程序的版式追求清晰、美观，是

程序风格的重要构成因素。

        可以把程序的版式比喻为“书法”。好的“书法”可让人对程序一目了然，看得兴致勃勃。差的程序“书法”如螃蟹爬行，让人看得索然无味，更令维护者烦恼有加。请程序员们学习程序的“书法”，弥补大学计算机教育的漏洞，实在很有必要。

        书中的这段引言深刻指出了我们当代大部分计算机学者的弊病，想要成为一位合格的程序员，程序的版式是尤为重要的。下面我通过读本书的体会，为各位讲述一下正确的程序版式和优秀的风格。 

一、 空行

二、 代码行

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

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

        *  另外，尽可能在定义变量的同时初始化该变量（就近原则），如果变量的引用处和其定义处相隔比较远，变量的初始化很容易被忘记。如果引用了未被初始化的变量，可能会导致程序错误。就近初始化可以很好的避免该隐患的出现。

三、代码行内的空格

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

2、函数名之后不要留空格，紧跟左括号‘（’，以与关键字区别。

3、‘（’向后紧跟；   ‘）’、‘，’、‘;’向前紧跟；紧跟处不留空格。

4、‘，’之后要留空格，如 Function(x, y, z)。如果‘;’不是一行的结束符号，其后要留空格，如 ：for (initialization; condition; update)。

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

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

7、像“［］”、“.”、“->”这类操作符前后不加空格。

8、对于表达式比较长的 for 语句和 if 语句，为了紧凑起见可以适当地去掉一些空格，如 ：

for (i=0; i<10; i++)和 if ((a<=b) && (c<=d))

四、对齐

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

2、{ } 之内的代码块在‘ { ’右边数格处左对齐。

五、长行拆分

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

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

六、修饰符的位置

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

2、 若将修饰符 * 靠近数据类型，例如：int* x; 从语义上讲此写法比较直观，即 x是 int 类型的指针。 但这种写法的弊端是容易引起误解，例如：int* x, y; 此处 y 容易被误解为指针变 量。虽然将 x 和 y 分行定义可以避免误解，但并不是人人都愿意这样做。

3、我们 应当将修饰符 * 和 ＆ 紧靠变量名。 例如：

char  *name;

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

七、注释 

i++; // i 加 1，多余的注释

3、 边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。不再有用的注释要删除。

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

5、尽量避免在注释中使用缩写，特别是不常用缩写。

6、注释的位置应与被描述的代码相邻，可以放在代码的上方或右方，不可放在下方。

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

八、类的版式

        这里是C++里的内容，以后有机会会将。

1、将 private 类型的数据写在前面，而将 public 类型的函数写在后面，采用这种版式的程序员主张类的设计“以数据为中心”，重点关注类的内部结构。

2、将 public 类型的函数写在前面，而将 private 类型的数据写在后面，采用这种版式的程序员主张类的设计“以行为为中心”，重点关注的是类应该提供什么样的接口（或服务）。

         很多 C++教课书受到 Biarne Stroustrup 第一本著作的影响，不知不觉地采用了“以

数据为中心”的书写方式，并不见得有多少道理。

        我建议读者采用“以行为为中心”的书写方式，即首先考虑类应该提供什么样的函 数。这是很多人的经验——“这样做不仅让自己在设计类时思路清晰，而且方便别人阅 读。因为用户最关心的是接口，谁愿意先看到一堆私有数据成员！”