C 编程最佳实践

2016-02-19 12:34 3 1 收藏

给自己一点时间接受自己,爱自己,趁着下午茶的时间来学习图老师推荐的C 编程最佳实践,过去的都会过去,迎接崭新的开始,释放更美好的自己。

【 tulaoshi.com - 编程语言 】


  C 编程最佳实践
  原文地址:[url]http://www-900.ibm.com/developerWorks/cn/Linux/l-bppc/index.sHtml[/url]
  [size=18:db26774567][b:db26774567]简介
  风格与指南
  其它
  结束语
  参考资料[/b:db26774567][/size:db26774567]
  Shiv Dutta(sdutta@us.ibm.com ),技术顾问,IBM
  Gary Hook(ghook@us.ibm.com),高级技术顾问,IBM
  
  2003 年 9 月
  尽管 C 语言问世已近 30 年,但它的魅力仍未减退。C 语言继续吸引着众多的人们,他们为了编写新的应用程序,或者移植或维护现有的应用程序而必须学习新技能。
  [size=18:db26774567][b:db26774567]简介[/b:db26774567][/size:db26774567]
  本文是为了满足开发人员的需要而写的。我们总结了一套指南,无论作为开发人员还是顾问,这些指南多年来一直都很好地指导着我们,我们把它们作为建议提供给您,希望对您的工作有所帮助。您也许不赞同其中的某些指南,但我们希望您会喜欢其中的一些并在您的编程或移植项目中使用它们。
  [size=18:db26774567][b:db26774567]风格与指南[/b:db26774567][/size:db26774567]
  •使用一种使代码具有可读性和一致性的源代码风格。假如没有团队代码风格或自己的风格,您可以使用与大多数 C 程序员采用的 Kernighan 和 Ritchie 风格相似的风格。然而,举一个极端的例子,有可能最终会写出与下面相似的代码:
  
  [code:1:db26774567]int i;main(){for(;i["]i;++i){--i;}"];read('-'-'-',i+++"hell
  o, world!",'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);[/code:1:db26774567]
  •— 1984 年模糊 C 代码大赛“差劲奖”。应代码作者要求匿名。
  •通常将主例程定义为 main()。对应的 ANSI 编写方式是 int main(void)(假如不考虑命令行参数的话)或 int main( int argc, char **argv 。ANSI 以前的编译器会省略 void 声明,或列出变量名以及紧随其后的声明。
  •空格
  充分利用水平和垂直空格。缩进和空格间距应反映出代码的块结构。
  应将条件运算符的长字符串分割成单独的几行。例如:
  
  [code:1:db26774567]if (foo-next==NULL && number limit && limit =SIZE
   && node_active(this_input)) {...[/code:1:db26774567]
  最好改成:
  
  [code:1:db26774567]if (foo-next == NULL
   && number limit && limit = SIZE
   && node_active(this_input))
  {
   ...[/code:1:db26774567]同样,应将描述得很具体的 for 循环分割成不同的行:
  
  [code:1:db26774567]for (curr = *varp, trail = varp;
   curr != NULL;
  trail = &(curr-next), curr = curr-next )
   {
   ...[/code:1:db26774567]对于其它复杂表达式(如使用三元运算符 ?: 的表达式),最好也将其分割成数行。
  
  [code:1:db26774567] z = (x == y)
   ? n + f(x)
   : f(y) - n;[/code:1:db26774567]
  
  •注释
  注释应描述正在发生什么事、如何完成它、参数表示什么、使用了哪些全局变量以及任何限制或错误。但要避免不必要的注释。假如代码比较清楚,并且使用了良好的变量名,那么它应该能够较好地说明自身。因为编译器不检查注释,所以不保证它们是正确的。与代码不一致的注释会起到相反的作用。过多的注释会使代码混乱。
  下面是一种多余的注释风格:
  
  [code:1:db26774567] i=i+1;/* Add one to i */[/code:1:db26774567]
  很明显变量 i 递增了 1。还有更糟的注释方法:
  
  
  [code:1:db26774567]/************************************
   **
   * Add one to i *
  **
  
   ************************************/
  
   i=i+1;[/code:1:db26774567]
  •命名约定
  具有前导和尾随下划线的名称是为系统用途而保留的,不应当用于任何用户创建的名称。约定规定:
  1. #define 常量应全部大写。
  2. enum 常量应以大写字母开头或全部大写。
  3. 函数、类型定义(typedef)和变量名以及结构(strUCt)、联合(union)和枚举(enum)标记名称应小写。
  为清楚起见,避免使用仅在大小写上有区别的名称,如 foo 和 Foo。同样,避免使用 Foobar 和 foo_bar 这样的名称。避免使用看上去相似的名称。在许多终端和打印机上,“l”、“1”和“I”看上去非常相似。使用名为“l”的变量非常不明智,因为它看上去非常象常量“1”。
  •变量名
  选择变量名时,长度不重要,但清楚的表达很重要。长名称可用于全局变量,因为它不常用,而将在每行循环上要使用的数组下标命名为 i 就完全够了。假如使用“index”或“elementnumber”的话,不仅输入得更多,而且会使计算的细节不明确。假如使用长变量名,有时候会使代码更难理解。比较:
  
  
  [code:1:db26774567] for(i=0 to 100)
   array[i]=0[/code:1:db26774567]
  和
  [code:1:db26774567] for(elementnumber=0 to 100)
   array[elementnumber]=0;[/code:1:db26774567]
  •函数名
  函数名应反映函数执行什么操作以及返回什么内容。函数在表达式中使用,通常用于 if 子句,因此它们的意图应一目了然。例如:
  [code:1:db26774567] if (checksize(x))[/code:1:db26774567]
  没有帮助作用,因为它没有告诉我们 checksize 是在出错时返回 true 还是在不出错时返回 true;而
  [code:1:db26774567] if (validsize(x))[/code:1:db26774567]
  则使函数的意图很明确。
  •声明
  所有的外部数据声明前都应加上 extern 要害字。
  “指针”限定符“*”应紧邻变量名而不是类型。例如,应使用
  
  
  [code:1:db26774567] char*s, *t, *u;[/code:1:db26774567]
  而不是
  
  
  [code:1:db26774567] char* s, t, u;[/code:1:db26774567]
  后一条语句没有错,但可能不是我们期望的,因为没有将“t”和“u”声明为指针。
  •头文件
  头文件应按功能组织在一起,即,对单独子系统的声明应在单独的头文件中。此外,当代码从一个平台移植到另一个平台时有可能发生更改的声明应位于单独的头文件中。
  避免使用与库头文件名相同的专用头文件名。语句 #include "math.h" 假如在当前目录中找不到所期望文件的话,会包括标准库 math 头文件。假如这是您期望的结果,可以注释掉这行 include 语句。
  最后说明一点,对头文件使用绝对路径名不是一个好主意。C 编译器的“include-path”选项(在许多系统上为 -I — 大写的 i)是处理众多专用头文件库的首选方法;它答应在不改变源文件的情况下重新组织目录结构。
  •scanf
  在重要的应用程序中永远不要使用 scanf。它的错误检测不够完善。请看下面的示例:
  
  
  [code:1:db26774567] #include stdio.h
  
  int main(void)
  {
  int i;
  float f;
  
  printf("Enter an integer and a float: ");
  scanf("%d %f", &i, &f);
  
  printf("I read %d and %f", i, f);
  return 0;
  }[/code:1:db26774567]
  测试运行
  Enter an integer and a float: 182 52.38
  I read 182 and 52.380001
  另一个测试运行
  Enter an integer and a float: 6713247896 4.4
  I read -1876686696 and 4.400000
  •++ 和 --
  当对语句中的变量使用递增或递减运算符时,该变量不应在语句中出现一次以上,因为求值的顺序取决于编译器。编写代码时不要对顺序作假设,也不要编写在某一机器上能够如期运作但没有明确定义的行为的代码:
  
  [code:1:db26774567] int i = 0, a[5];
  
  a[i] = i++; /* assign to a[0]? or a[1]? */[/code:1:db26774567]
  •不要被表面现象迷惑
  请看以下示例:
  
  
  
  [code:1:db26774567] while (c == '' c = ' ' c == '')
  c = getc(f);[/code:1:db26774567]
  乍一看,while 子句中的语句似乎是有效的 C 代码。但是,使用赋值运算符而不是比较运算符却产生了语义上不正确的代码。= 的优先级在所有运算符中是最低的,因此将以下列方式解释该语句(为清楚起见添加了括号):
  
  [code:1:db26774567] while ((c == '' c) = (' ' c == ''))
  c = getc(f);[/code:1:db26774567]
  赋值运算符左边的子句是:
  
  [code:1:db26774567] (c == '' c)[/code:1:db26774567]
  它不会产生左值。假如 c 包含制表符,则结果是“true”,并且不会执行进一步的求值,而“true”不能位于赋值表达式的左边。
  •意图要明确。
  当您编写的代码可以解释成另一种意图时,使用括号或用其它方法以确保您的意图清楚。假如您以后必须处理该程序的话,这有助于您理解您当初的意图。假如其他人要维护该代码,这可以让维护任务变得更简单。
  用能预见可能出现错误的方式编码,有时是可行的。例如,可以将常量放在比较等式的左边。即,不编写:
  
  [code:1:db26774567] while (c == '' c == ' ' c == '')
  c = getc(f);[/code:1:db26774567]
  而是编写:
  
  [code:1:db26774567] while ('' == c ' ' == c '' == c)
   c = getc(f);[/code:1:db26774567]
  用以下方法却会得到编译器诊断:
  
  [code:1:db26774567] while ('' = c ' ' == c '' == c)
   c = getc(f);[/code:1:db26774567]
  这种风格让编译器发现问题;上面的语句是无效的,因为它试图对“”赋值。
  •意想不到的麻烦。
  各种 C 实现通常在某些方面各有不同。坚持使用语言中可能对所有实现都是公共的部分会有帮助。通过这样做,您更轻易将程序移植到新的机器或编译器,并且不大会碰到编译器非凡性所带来的问题。例如,考虑字符串:
  
  [code:1:db26774567] /*/*/2*/**/1[/code:1:db26774567]
  这里利用了“最大适合(maximal munch)”规则。假如可以嵌套注释,则可将该字符串解释为:
  [code:1:db26774567] /* /* /2 */ * */ 1[/code:1:db26774567]
  两个 /* 符号与两个 */ 符号匹配,因此该字符串的值为 1。假如注释不嵌套,那么在有些系统上,注释中的 /* 就被忽略。在另一些系统上会针对 /* 发出警告。无论哪种情况,该表达式可解释为:
  
  [code:1:db26774567] /* / */ 2 * /* */ 1[/code:1:db26774567]
  2 * 1 求值得 2。
  •清空输出缓冲区
  当应用程序异常终止时,其输出的尾部经常会丢失。应用程序可能没有机会完全清空它的输出缓冲区。输出的某一部分可能仍在内存中,并且永远不会被写出。在有些系统上,这一输出可能有几页长。
  以这种方式丢失输出会使人误解,因为它给人的印象是程序在它实际失败很久之前就失败了。解决这一问题的方法是强制将输出从缓冲区清除,非凡是在调试期间。确切的方法随系统的不同而有所不同,不过也有常用的方法,如下所示:
  
  [code:1:db26774567] setbuf(stdout, (char *) 0);[/code:1:db26774567]
  必须在将任何内容写到标准输出之前执行该语句。理想情况下,这将是主程序中的第一条语句。
  •getchar() — 宏还是函数
  以下程序将其输入复制到其输出:
  
  
  [code:1:db26774567] #include stdio.h
  
  int main(void)
  {
  register int a;
  
  while ((a = getchar()) != EOF)
  putchar(a);
  }[/code:1:db26774567]
  从该程序除去 #include 语句将使该程序无法编译,因为 EOF 将是未定义的。
  我们可以用以下方法重新编写该程序:
  
  
  [code:1:db26774567] #define EOF -1
  
  int main(void)
  {
  register int a;
  
  while ((a = getchar()) != EOF)
  putchar(a);
  }[/code:1:db26774567]
  这在许多系统上都可行,但在有些系统上运行要慢很多。
  因为函数调用通常要花较长时间,所以经常把 getchar 实现为宏。这个宏定义在 stdio.h 中,所以当除去 #include stdio.h 时,编译器就不知道 getchar 是什么。在有些系统上,假设 getchar 是返回一个 int 的函数。
  实际上,许多 C 实现在其库中都有 getchar 函数,部分原因是为了防止这样的失误。于是,在 #include stdio.h 遗漏的情况下,编译器使用 getchar 的函数版本。函数调用的开销使程序变慢。putchar 有同样的问题。
  •空指针
  空指针不指向任何对象。因此,为了赋值和比较以外的目的而使用空指针都是非法的。
  不要重新定义 NULL 符号。NULL 符号应始终是常量值零。任何给定类型的空指针总是等于常量零,而与值为零的变量或与某一非零常量的比较,其行为由实现定义。
  
   反引用 null 指针可能会导致希奇的事情发生。
  •a+++++b 表示什么?
  解析它的唯一有意义的方法是:
  
  [code:1:db26774567] a ++ + ++ b[/code:1:db26774567]
  然而,“最大适合”规则要求将它分解为:
  
  [code:1:db26774567] a ++ ++ + b[/code:1:db26774567]
  这在语法上是无效的:它等于:
  
  [code:1:db26774567] ((a++)++) + b[/code:1:db26774567]
  但 a++ 的结果不是左值,因此作为 ++ 的操作数是不可接受的。于是,解析词法不明确性的规则使得以语法上有意义的方式解析该示例变得不可能。当然,谨慎的办法实际上是在不能完全确定它们的意义的情况下,避免这样的构造。当然,添加空格有助于编译器理解语句的意图,但(从代码维护的角度看)将这一构造分割成多行更可取:
  
  [code:1:db26774567] ++b;
  (a++) + b;[/code:1:db26774567]
  •小心处理函数
  函数是 C 中最常用的结构概念。它们应用于实现“自顶向下的”问题解决方法 — 即,将问题分解成越来越小的子问题,直到每个子问题都能够用代码表示。这对程序的模块化和文档记录有帮助。此外,由许多小函数组成的程序更易于调试。
  假如有一些函数参数还不是期望的类型,则将它们强制转换为期望的类型,即使您确信没有必要也应该这样做,因为(假如不转换的话)它们可能在您最意料不到的时候给您带来麻烦。换句话说,编译器通常将函数参数的类型提升和转换成期望的数据类型以符合函数参数的声明。但是,在代码中以手工方式这样做可以清楚地说明程序员的意图,并且在将代码移植到其它平台时能确保有正确的结果。
  假如头文件未能声明库函数的返回类型,那就自己声明它们。用 #ifdef/#endif 语句将您的声明括起来,以备代码被移植到另一个平台。
  函数原型应当用来使代码更健壮,使它运行得更快。
  •悬空 else
  除非知道自己在做什么,否则应避免“悬空 else”问题:
  
  
  [code:1:db26774567] if (a == 1)
  if (b == 2)
  printf("***");
  else
  printf("###");[/code:1:db26774567]
  
  规则是 else 附加至最近的 if。当有疑虑时,或有不明确的可能时,添加花括号以说明代码的块结构。
  •数组界限
  检查所有数组的数组界限,包括字符串,因为在您现在输入“fubar”的地方,有人可能会输入“floccinaucinihilipilification”。健壮的软件产品不应使用 gets()。
  C 下标以零作为开始的这一事实使所有的计数问题变得更简单。然而,把握如何处理它们需要花些努力。
  •空语句
  for 或 while 循环的空语句体应当单独位于一行并加上注释,这样就表明这个空语句体是有意放置的,而不是遗漏了代码。
  
  [code:1:db26774567] while (*dest++ = *src++)
   ; /* VOID */[/code:1:db26774567]
  •测试真(true)还是假(false)
  不要以缺省方式测试非零值,即:
  
  [code:1:db26774567] if (f() != FAIL)[/code:1:db26774567]
  优于
  
  [code:1:db26774567] if (f())[/code:1:db26774567]
  尽管 FAIL 的值可能是 0(在 C 中视为假(false))。(当然,应当在这一风格与“函数名”一节中演示的构造之间作出权衡。)当以后有人认为失败的返回值应该是 -1 而不是 0 时,显式的测试对您会有帮助。
  常见的问题是使用 strcmp 函数测试字符串是否相等,决不应该以缺省方式处理它的结果。更可取的方法是定义宏 STREQ:
  
  [code:1:db26774567]#define STREQ(str1, str2) (strcmp((str1), (str2)) == 0)[/code:1:db26774567]
  用这种方法,语句
  
  [code:1:db26774567] If ( STREQ( inputstring, somestring ) ) ...[/code:1:db26774567]
  就具有隐含的行为,该行为不大会在您不知情的情况下改变(人们往往不会重新编写或重新定义象 strcmp() 这样的标准库函数)。
  不要用 1 检查相等性的布尔值(TRUE 和 YES 等);而要用 0 测试不等性(FALSE 和 NO 等)。绝大多数函数被确保在条件为假(false)时返回 0,但仅在条件为真(true)时才返回非零。因此,最好将
  
  [code:1:db26774567] if (func() == TRUE) {...[/code:1:db26774567]
  写成
  
  [code:1:db26774567] if (func() != FALSE)[/code:1:db26774567]
  •嵌入语句
  使用嵌入赋值语句要看时间和地点。在有些构造中,假如不使用更多且不易阅读的代码就没有更好的方法来实现结果:
  
  [code:1:db26774567] while ((c = getchar()) != EOF) {
   process the character
  }[/code:1:db26774567]
  使用嵌入赋值语句来提高运行时性能是可能的。但是,您应当在提高速度和降低可维护性之间加以权衡,在人为指定的位置使用嵌入赋值语句会导致可维护性降低。例如:
  
  
  [code:1:db26774567] x = y + z;
  d = x + r;[/code:1:db26774567]
  不应被替换为:
  
  [code:1:db26774567] d = (x = y + z) + r;[/code:1:db26774567]
  即使后者可能节省一个周期也不行。最终,这两者之间在运行时间上的差异将随着优化器的增强而减少,易维护性的差异却将增加。
  •goto 语句
  应保守地使用 goto。从数层 switch、for 和 while 嵌套中跳出来时,使用该语句很有效,不过,假如有这样的需要,则表明应将内部构造分解成单独的函数。
  
  [code:1:db26774567] for (...) {
   while (...) {
   ...
  if (wrong)
   goto error;
  
   }
   }
   ...
  error:
   print a message[/code:1:db26774567]
  当必须使用 goto 时,随附的标号应单独位于一行,并且同后续代码的左边相距一个制表符或位于一行的开头。对 goto 语句和目标都应加上注释,说明其作用和目的。
  •switch 中的“落空”(fall-through)
  当一块代码有数个标号时,将这些标号放在单独的行。这种风格与垂直空格的使用一致,并且使重新安排 case 选项(假如那是必需的话)成了一项简单的任务。应对 C switch 语句的“落空”特征加以注释,以便于以后的维护。假如这一特性曾给您带来“麻烦”,那么您就能够理解这样做的重要性!
  
  [code:1:db26774567] switch (eXPr) {
  case ABC:
  case DEF:
   statement;
   break;
  case UVW:
   statement; /*FALLTHROUGH*/
  case XYZ:
   statement;
   break;
  }[/code:1:db26774567]
  尽管从技术上说,最后一个 break 不是必需的,但是,假如以后要在最后一个 case 之后添加了另一个 case,那么一致地使用 break 可以防止“落空”错误。假如使用 default case 语句的话, 它应当永远是最后一个,并且(假如它是最后的语句)不需要最后的 break 语句。
  •常量
  符号常量使代码更易于阅读。应尽量避免使用数字常量;使用 C 预处理器的 #define 函数给常量赋予一个有意义的名称。在一个位置(最好在头文件中)定义值还会使得治理大型程序变得更轻易,因为只需更改定义就可以统一地更改常量值。可以考虑使用枚举数据类型作为对声明只取一组离散值的变量的改进方法。使用枚举还可以让编译器对您枚举类型的任何误用发出警告。任何直接编码的数字常量必须至少有一个说明值的出处的注释。
  常量的定义与它的使用应该一致;例如,将 540.0 用于浮点数,而不要通过隐式浮点类型强制转换使用 540。也就是说,在有些情况下,常量 0 和 1 可以以本身的形式直接出现,而不要以定义的形式出现。例如,假如某个 for 循环遍历一个数组,那么:
  
  [code:1:db26774567] for (i = 0; i arraysub; i++)[/code:1:db26774567]
  非常合理,而代码:
  
  [code:1:db26774567] gate_t *front_gate = opens(gate[i], 7);
  if (front_gate == 0)
   error("can't open %s", gate[i]);[/code:1:db26774567]
  就不合理。在第二个示例中,front_gate 是指针;当值是指针时,它应与 NULL 比较而不与 0 比较。即使象 1 或 0 这样的简单值,通常最好也使用象 TRUE 和 FALSE 这样的定义来表示(有时 YES 和 NO 读起来更清楚)。
  不要在需要离散值的地方使用浮点变量。这是由于浮点数不精确的表示决定的(请参阅以上 scanf 中的第二个测试)。使用 = 或 = 测试浮点数;精确比较(== 或 !=)也许不能检测出“可接受的”等同性。
  应将简单的字符常量定义为字符文字而不是数字。不提倡使用非文本字符,因为它们是不可移植的。假如必须使用非文本字符,尤其是在字符串中使用它们,则应使用三位八进制数(不是一个字符)的转义字符(例如“

来源:https://www.tulaoshi.com/n/20160219/1601207.html

延伸阅读
(1)“我的程序都是对的,可结果不对” 想想你的四周,是不是也有人说这样的话?假如你也曾经说过,那就此打住,不要再说这句话,因为这句话只会显示说话者的无知。既然程序都是对的,那为什么结果不对? (2)“程序=算法+数据结构” 假如刚刚学完C语言,我们说这样的话,完全可以理解,而且可以说是正确的。但是假如你是一位即将...
1.引言 !-- frame contents -- !-- /frame contents -- 还记得当年学数学、英语都有个窍门,那就是搞个错题集。经常复习一下这个错题集,就可以避免下次犯同样的错误。而几乎所有的程序员都是从犯错误开始的,我们也很有必要总结一下编程新手的常见错误,本文的目的在于此。文中所列出的都是笔者在项目开发中接...
标签: Web开发
这是我很早以前看过的微软的一篇文章,最近,一些网友问的问题很多理论都在里面,所以,整理一下放在这里,大家可以参考一下。 简介 本文为您提供了在 Microsoft ADO.NET 应用程序中实现和获得最佳性能、可伸缩性以及功能的最佳解决方案;同时也讲述了使用 ADO.NET 中可用对象的最佳实践;并提出一些有助于优化 ADO.NET 应用程序设计的建议。 ...
我们知道C#和C++的差异之一,就是他本身没有类库,所使用的类库是.Net框架中的类库--.Net FrameWork SDK。在.Net FrameWork SDK中为网络编程提供了二个名称空间:"System.Net"和"System.Net.Sockets"。C#就是通过这二个名称空间中封装的类和方法实现网络通讯的。 首先我们解释一下在网络编程时候,经常遇到的...
标签: Web开发
这本来是翻译Estelle Weyl的《15 JavaScript Gotchas》,里面介绍的都是在JavaScript编程实践中平时容易出错或需要注意的地方,并提供避开这些陷阱的方法,总体上讲,就是在认清事物本质的基础样要坚持好的编程习惯,其实这就是Douglas Crockford很久以前提出的JavaScript风格要素问题了,有些内容直接是相同的。在翻译的过程中,我又看到了...

经验教程

712

收藏

96
微博分享 QQ分享 QQ空间 手机页面 收藏网站 回到头部