-
xzsdn_08
 
 - 注册时间 01-04-2009
- 江苏徐州
- 发帖总数 641
|
- 18.1 什么是 C 最好的代码布局风格？
- 18.2 用 if(!strcmp(s1, s2)) 比较两个字符串等值,是否是个好风格？
- 18.3 为什么有的人用 if (0 == x) 而不是 if (x == 0)？
- 18.4 原型说明 extern int func __((int, int)); 中, 那些多出来的括号和下划线代表了什么？
- 18.5 为什么有些代码在每次调用 printf() 前, 加了类型转换 (void)？
- 18.6 什么是 ``匈牙利标志法" (Hungarian Notation)？是否值得用？
- 18.7 哪里可以找到 ``印第安山风格指南" (Indian Hill Style Guide) 及其它编码标准？
- 18.8 有些人说 goto 是邪恶的, 我应该永不用它。那是否太极端了？
18.1 什么是 C 最好的代码布局风格？
K&R 提供了最常被抄袭的实例, 同时他并不要求大家沿用他的风格:
大括号的位置并不重要, 尽管人们对此有着执着的热情。我们在几种流行的风格中选了一种。选一个适合你的风格, 然后坚持使用这一风格。
保持布局风格对自己, 对邻近及通用源代码的一致比使之完美跟重要。如果你的编码环境 (本地习惯或公司政策) 没有建议一个风格, 你也不想发明自己的风格, 可以沿用 K&R 中的风格。各种缩进和大括号的放置之间的好与坏可以详尽而细致地探讨, 但本文不再次重复了。可以参见《印第安山风格指南》(Indian Hill Style Guide), 问题 17.7。
``好风格" 的品质并不简单, 它包含的内容远远不止代码的布局细节。不要把时间都花在格式上而忽略了更实质性的代码本身的质量。
参见问题 10.4。
参考资料: [K&R1, Sec. 1.2 p. 10]; [K&R2, Sec. 1.2 p. 10]。
18.2 用 if(!strcmp(s1, s2)) 比较两个字符串等值,是否是个好风格？
这并不是个很好的风格, 虽然这是个流行的习惯用法。如果两个字符串相等, 这个测试返回为真, 但 ! (``非") 的使用, 容易引起误会, 以为测试不等值情况。
另一个选择是用一个宏:
#define Streq(s1, s2) (strcmp((s1), (s2)) == 0)
参见问题 17.8。
18.3 为什么有的人用 if (0 == x) 而不是 if (x == 0)？ 这是用来防护一个通常错误的小技巧:
if (x = 0)
如果你养成了把常量放在 == 前面的习惯, 当你意外的把代码写成了:
if (0 = x)
那编译器就会报怨。明显的, 一些人会觉得记住反换测试比记住输入双 = 号容易。当然这个技巧只对和常量比较的情况有用。
参考资料: [H&S, Sec. 7.6.5 pp. 209-10]。
18.4 原型说明 extern int func __((int, int)); 中, 那些多出来的括号和下划线代表了什么？ 这是为了可以在使用 ANSI 以前的编译器时, 关掉说明中的原型部分。这是技巧的一部分。
在别的地方, 宏 __ 被定义为类似下面的代码：
#ifdef __STDC__
#define __(proto) proto
#else
#define __(proto) ()
#endif
原型说明中额外的括号是为了让原型列表被当作宏的单一参数。
18.5 为什么有些代码在每次调用 printf() 前, 加了类型转换 (void)？ printf() 确实返回一个值, 虽然极少数程序员去检验每次调用的返回值。由于有些编译器和 lint 对于被丢弃的返回值会报警告, 清楚的用 (void) 作类型转换相当于说: ``我决定忽略这次调用的返回值, 请继续对于其他忽略返回值的情况 (也许是不应该的) 提出警告。" 通常, 无值类型转换也用于 strcpy() 和 strcat() 的调用, 他们的返回值从不会令人惊讶。
参考资料: [K&R2, Sec. A6.7 p. 199]; [Rationale, Sec. 3.3.4]; [H&S, Sec. 6.2.9 p. 172, Sec. 7.13 pp. 229-30]。
18.6 什么是 ``匈牙利标志法" (Hungarian Notation)？是否值得用？ 匈牙利标志法是一种命名约定, 由 Charles Simonyi 发明。他把变量的类型 (或者它的预期使用) 等信息编码在变量名中。在某些圈子里, 它被高度热爱, 而在另一些地方, 它被严厉地批评。它的主要优势在于变量名就说明了它的类型或者使用。它的主要缺点在于类型信息并不值得放在变量名中。
参考资料: [Simonyi&Heller]。
18.7 哪里可以找到 ``印第安山风格指南" (Indian Hill Style Guide) 及其它编码标准？ 各种文档在匿名 ftp 都可以得到：
| 地址 |
文档及目录 |
| ftp.cs.washington.edu |
pub/cstyle.tar.Z |
| |
(更新的印第安山风格指南, (Indian Hill Guide)) |
| ftp.cs.toronto.edu |
doc/programming |
| |
(包括 Henry Spencer 的《C 程序员的十诫》 (``10 Commandments for C Programmers")) |
| ftp.cs.umd.edu |
pub/style-guide |
也许你会对这些书感兴趣: 《The Elements of Programming Style》[K&P], 《Plum Hall Programming Guidelines》[Plum], 《C Style: Standards and Guidelines》[Straker]。参见文献 [21]。
参见问题 18.7。
18.8 有些人说 goto 是邪恶的, 我应该永不用它。那是否太极端了？ 程序设计风格, 就象写作风格一样, 是某种程度的艺术, 不可以被僵化的教条所束缚。虽然风格的探讨经常都是围绕着这些条例。
对于 goto 语句, 很早以前, 就被注意到, 随意的使用 goto 会很快的导致象面糊一样难以维护的代码。然而, 不经思考就简单的禁止 goto 的使用, 并不能立即导至好程序。一个无规划的程序员可以不用任何 goto 语句而构造出复杂难解的代码, 也许使用奇怪的嵌套循环和布尔变量来取代 goto。
通常, 把这些程序设计风格的评论或者 ``条例" 当作指导准则比当作条例要更好。当程序员理解这些指导准则所要实现的目标, 就会工作的更加之好。盲目的回避某种构造或者死套条例而不融会贯通, 最终还会导致这些条例试图避免的问题。
此外, 许多程序设计风格的意见只是意见。通常卷入 ``风格战争" 是毫无意义的。某些问题 (象问题 5.3, 5.7, 9.2 和 10.5), 争辩的双方是不可能同意, 认同对方的不同或者是停止争论的。
|
|