《Recommended C Style and Coding Standards》学习总结

1.     命名规范

• 以下划线开头或结尾的名称为系统保留
• #define定义的宏常量用大写
• 枚举常量名用大写
• 函数名、类型定义typedef名、变量名以及struct、union和enum标记名用小写
• 宏函数名用大写，除非该宏函数的使用看起来就像是函数调用，例如getchar和putchar宏
• 避免不同的名称只靠大小写区分，例如foo和Foo，foobar和foo_bar
• 避免名称相似，比如‘l’、‘1’、‘I’，变量名I很容易被误看作常量1
• 全局变量名以前缀g_开头，类型定义的新类型以_t结尾
• 避免与标准库中的名称重复
•  

2.    宏

• 函数宏定义时特别要注意由此可能出现的操作符优先级问题以及一些不可预料的匹配问题

3.    可移植性（留作以后单独讨论）

4.   ANSI C（不太懂）

• Compatibility
• Formatting
• Prototypes
• Pragmas

5.  需要特别注意的7点

• Don't change syntax via macro substitution.
• Don't use floating-point variables where discrete values are needed.
• Compilers have bugs.
• Do not rely on automatic beautifiers.
• Accidental omission of the second "=" of the logical compare is a problem.
• Explicitly comment variables that are changed out of the normal control flow, or other code that is
  likely to break during maintenance.
• Modern compilers will put variables in registers automatically.

6.  Lint

• Lint使用简介：http://blog.csdn.net/zxj2008cn/archive/2006/05/11/725230.aspx

7. Make

8. Project-Dependent Standards

• What additional naming conventions should be followed?
• What kind of include file organization is appropriate for the project’s particular data hierarchy?
• What procedures should be established for reviewing lint complaints?
• If a project establishes its own archive libraries, it should plan on supplying a lint library file to
  the system administrators. The lint library file allows lint to check for compatible use of library
  functions.
• What kind of revision control needs to be used?

9. 总结

         最重要的四点

• The proper use of white space and comments so that the structure of the program is evident from the
  layout of the code.
• The use of simple expressions, statements, and functions so that they may be understood easily.
• To keep in mind that you or someone else will likely be asked to modify code or make it run on a
  different machine sometime in the future. Craft code so that it is portable to obscure machines. Localize
  optimizations since they are often confusing and may be "pessimizations" on other machines.
• Many style choices are arbitrary. Having a style that is consistent (particularly with group standards)
  is more important than following absolute style rules. Mixing styles is worse than using any single
  bad style.