今天我们来聊轻松些的话题——C语言代码风格。

7.1 什么是 C 最好的代码布局风格？

17.2 用 if(!strcmp(s1, s2)) 比较两个字符串等值,是否是个好风格？

17.3 为什么有的人用 if (0 == x) 而不是 if (x == 0)？

17.4 原型说明 extern int func ((int, int)); 中, 那些多出来的括号和下 划线代表了什么？

17.5 为什么有些代码在每次调用 printf() 前, 加了类型转换 (void)？

17.6 什么是 “匈牙利标志法” (Hungarian Notation)？是否值得用？

17.7 哪里可以找到 “印第安山风格指南” (Indian Hill Style Guide) 及 其它编码标准？

17.1 什么是 C 最好的代码布局风格？

K&R 提供了最常被抄袭的实例, 同时他并不要求大家沿用他的风格:

大括号的位置并不重要, 尽管人们对此有着执着的热情。我们在几种流行的风格中选了一种。选一个适合你的风格, 然后坚持使用这一风格。

保持布局风格对自己, 对邻近及通用源代码的一致比使之完美跟重要。如果你的编码环境 (本地习惯或公司政策) 没有建议一个风格, 你也不想发明自己的风格, 可以沿用 K&R 中的风格。各种缩进和大括号的放置之间的好与坏可以详尽而细致地探讨, 但本文不再次重复了。可以参见《印第安山风格指南》(Indian HillStyle Guide), 问题 17.7。

“好风格” 的品质并不简单, 它包含的内容远远不止代码的布局细节。不要把时间都花在格式上而忽略了更实质性的代码本身的质量。

17.2 用 if(!strcmp(s1, s2)) 比较两个字符串等值,是否是个好风格？

这并不是个很好的风格, 虽然这是个流行的习惯用法。如果两个字符串相等,

这个测试返回为真, 但 ! (“非”) 的使用, 容易引起误会, 以为测试不等值情况。

另一个选择是用一个宏:

#define Streq(s1, s2) (strcmp((s1), (s2)) == 0)

参见问题 17.8。

17.3 为什么有的人用 if (0 == x) 而不是 if (x == 0)？

这是用来防护一个通常错误的小技巧:

if (x = 0)

如果你养成了把常量放在 == 前面的习惯, 当你意外的把代码写成了:

if (0 = x)

那编译器就会报怨。明显的, 一些人会觉得记住反换测试比记住输入双 = 号容易。当然这个技巧只对和常量比较的情况有用。

17.4 原型说明 extern int func ((int, int)); 中, 那些多出来的括号和下划线代表了什么？

这是为了可以在使用 ANSI 以前的编译器时, 关掉说明中的原型部分。这是技巧的一部分。

在别的地方, 宏被定义为类似下面的代码：

#ifdef __STDC__

#define __(proto) proto

#else

#define __(proto) ()

#endif

原型说明中额外的括号是为了让原型列表被当作宏的单一参数。

17.5 为什么有些代码在每次调用 printf() 前, 加了类型转换 (void)？

printf() 确实返回一个值, 虽然极少数程序员去检验每次调用的返回值。由于有些编译器和 lint 对于被丢弃的返回值会报警告, 清楚的用 (void) 作类型转换相当于说: “我决定忽略这次调用的返回值, 请继续对于其他忽略返回值的情况 (也许是不应该的) 提出警告。” 通常, 无值类型转换也用于 strcpy() 和 strcat() 的调用,他们的返回值从不会令人惊讶。

17.6 什么是 “匈牙利标志法” (Hungarian Notation)？是否值得用？

匈牙利标志法是一种命名约定, 由 Charles Simonyi 发明。他把变量的类型(或者它的预期使用) 等信息编码在变量名中。在某些圈子里, 它被高度热爱, 而在另一些地方, 它被严厉地批评。它的主要优势在于变量名就说明了它的类型或者使用。它的主要缺点在于类型信息并不值得放在变量名中。

17.7 哪里可以找到 “印第安山风格指南” (Indian Hill Style Guide) 及其它编码标准？

17.8 有些人说 goto 是邪恶的, 我应该永不用它。那是否太极端了？

程序设计风格, 就象写作风格一样, 是某种程度的艺术, 不可以被僵化的教条所束缚。虽然风格的探讨经常都是围绕着这些条例。

对于 goto 语句, 很早以前, 就被注意到, 随意的使用 goto 会很快的导致象面糊一样难以维护的代码。然而, 不经思考就简单的禁止 goto 的使用, 并不能立即导至好程序。一个无规划的程序员可以不用任何 goto 语句而构造出复杂难解的代码, 也许使用奇怪的嵌套循环和布尔变量来取代 goto。

通常, 把这些程序设计风格的评论或者 “条例” 当作指导准则比当作条例要更好。当程序员理解这些指导准则所要实现的目标, 就会工作的更加之好。盲目的回避某种构造或者死套条例而不融会贯通, 最终还会导致这些条例试图避免的问题。

此外, 许多程序设计风格的意见只是意见。通常卷入 “风格战争” 是毫无意义的。某些问题 (象问题 5.3, 5.7, 9.2 和 10.5), 争辩的双方是不可能同意, 认同对方的不同或者是停止争论的。