C语言编程规范学习笔记

学习目的：
1.提高输出的代码质量,增强维护性,方便移植,代码风格相对统一

一、代码总体原则
1.清晰、简洁、同一个团队代码风格保持一致。

二、具体规范介绍
1.头文件
  原则1.1 头文件中适合放置接口的声明，不适合放置实现。
  原则1.2 头文件应当职责单一。
  原则1.3 头文件应向稳定的方向包含。
  原则1.4 避免头文件互相包含,节省编译时间
  原则1.5 每一个.c文件应有一个同名.h文件，用于声明需要对外公开的接口。
  原则1.6 禁止在头文件中定义变量。
  原则1.7 禁止在extern "C"中包含头文件。
  原则1.8 头文件应当自包含
  
说明：

自包含就是任意一个头文件均可独立编译。如果一个文件包含某个头文件，
还要包含另外一个头文件才能工作的话，就会增加交流障碍，给这个头文件的用户增添不必要的负担。  
  

2.函数和变量
  函数：
    函数设计的精髓：编写整洁函数，同时把代码有效组织起来。
      原则1.1 一个函数仅完成一项功能。
      原则1.2 函数代码尽可能精简，不冗余
      原则1.3 避免函数的代码块嵌套过深，新增函数的代码块嵌套不超过4层。
      原则1.4 可重入函数应避免使用共享变量；若需要使用，则应通过互斥手段进行保护,类似加锁机制。
      原则1.5 对函数入参进行校验
      原则1.6 对函数的错误返回码要全面处理。
      原则1.7 函数不变参数使用const。
      原则1.8 函数应避免使用全局变量、静态局部变量和I/O操作，不可避免的地方应集中使用。
      原则1.9 函数的参数个数不超过5个
      原则1.10 文件内部函数定义为static类型
  变量：
      原则1.1 一个变量只有一个功能，不能把一个变量用作多种用途。
      原则1.2 结构功能单一；不要设计面面俱到的数据结构。
      原则1.3 不用或者少用全局变量。
      原则1.4 通讯过程中使用的结构，必须注意字节序。
      原则1.5 变量必须初始化
      原则1.6 构造仅有一个模块或函数可以修改、创建，而其余有关模块或函数只访问的全局变量，
              防止多个不同模块或函数都可以修改、创建同一全局变量的现象。
      原则1.7 通过接口访问变量
      原则1.8 明确全局变量的初始化顺序，避免跨模块的初始化依赖。
      原则1.9 尽量减少没有必要的数据类型默认转换与强制转换。 
       
      
  
 
3.命名规则
  
  标识符通用命名规则：
  原则1.1 标识符的命名要清晰、明了，有明确含义，同时使用完整的单词或大家基本可以理解的缩写，避免使人产生误解。
  原则1.2 产品/项目组内部应保持统一的命名风格。
  原则1.3 尽量避免名字中出现数字编号，除非逻辑上的确需要编号。
  原则1.4 平台/驱动等适配代码的标识符命名风格保持和平台/驱动一致。
    文件命名规则：
    原则1.1 文件命名统一采用小写字符。
    变量命名规则：
    原则1.1 全局变量应增加“g_”前缀。
    原则1.2 静态变量应增加“s_”前缀。
    原则1.3 禁止使用单字节命名变量，但允许定义i、j、k作为局部循环变量。
    函数命名规则：
    原则1.1 函数命名应以函数要执行的动作命名，一般采用动词或者动词＋名词的结构。
    原则1.2 函数指针除了前缀，其他按照函数的命名规则命名。
    宏的命名规则：
    原则1.1 对于数值或者字符串等等常量的定义，建议采用全大写字母，单词之间加下划线‘_’的方式命名(枚举同样建议使用此方式定义)。
    原则1.2 除了头文件或编译开关等特殊标识定义，宏定义不能使用下划线‘_’开头和结尾。
 
4.宏、常量：
  原则1.1 用宏定义表达式时，要使用完备的括号。
  原则1.2 将宏所定义的多条表达式放在大括号中。
  原则1.3 使用宏时，不允许参数发生变化。
  原则1.4 不允许直接使用魔鬼数字。
  原则1.5 除非必要，应尽可能使用函数代替宏。
  原则1.6 常量建议使用const定义代替宏。
  原则1.7 宏定义中尽量不使用return、goto、continue、break等改变程序流程的语句。 
   
三、代码质量保证   
  原则1.1 代码质量保证优先原则
  原则1.2 必须了解编译系统的内存分配方式，特别是编译系统对不同类型的变量的内存分配规则，如局部变量在何处分配、静态变量在何处分配等。
  原则1.3 禁止内存操作越界,禁止内存泄漏,提防野指针
  原则1.4 申请的内存要及时的进行释放
  原则1.5 不要滥用goto语句。
  原则1.6 注意临界值问题     
 
四、程序效率
  原则1.1 在保证软件系统的正确性、简洁、可维护性、可靠性及可测性的前提下，提高代码效率。
  原则1.2 通过对数据结构、程序算法的优化来提高效率。
  原则1.3 对于多维大数组，避免来回跳跃式访问数组成员。
  原则1.4 创建资源库，以减少分配对象的开销。
  原则1.5 将多次被调用的“小函数”改为inline函数或者宏实现。
   
五、注释
  原则1.1 优秀的代码可以自我解释，不通过注释即可轻易读懂。
  原则1.2 注释的内容要清楚、明了，含义准确，防止注释二义性。
  原则1.3 修改代码时，维护代码周边的所有注释，以保证注释与代码的一致性。不再有用的注释要删除。
  原则1.4 函数声明处注释描述函数功能、性能及用法，包括输入和输出参数、函数返回值、可重入的要求等；
          定义处详细描述函数功能和实现要点，如实现的简要步骤、实现的理由、设计约束等。
  原则1.5 全局变量要有较详细的注释，包括对其功能、取值范围以及存取时注意事项等的说明。
  原则1.6 注释应放在其代码上方相邻位置或右方，不可放在下面。如放于上方则需与其上面的代码用空行隔开，且与下方代码缩进相同。
  原则1.7 对于switch语句下的case语句，如果因为特殊情况需要处理完一个case后进入下一个case处理，
          必须在该case语句处理完、下一个case语句前加上明确的注释。
  原则1.8 文件头、函数头、全局常量变量、类型定义的注释格式采用工具可识别的格式  

六、排版与格式
  原则1.1 程序块采用缩进风格编写，每级缩进为4个空格。
  原则1.2 相对独立的程序块之间、变量说明之后必须加空行。
  原则1.3 if、for、do、while、case、switch、default等语句独占一行。
      
七、代码编辑、编译
  原则1.1 使用编译器的最高告警级别，理解所有的告警，通过修改代码而不是降低告警级别来消除所有告警。
  原则1.2 在产品软件(项目组)中，要统一编译开关、静态检查选项以及相应告警清除策略。
  原则1.3 本地构建工具(如PC-Lint)的配置应该和持续集成的一致。
  原则1.4 使用版本控制(配置管理)系统，及时签入通过本地构建的代码，确保签入的代码不会影响构建成功。
  原则1.5 要小心地使用编辑器提供的块拷贝功能编程。
  
八、可测性  
  原则1.1 模块划分清晰，接口明确，耦合性小，有明确输入和输出，否则单元测试实施困难。
  原则1.2 在同一项目组或产品组内，要有一套统一的为集成测试与系统联调准备的调测开关及相应打印函数，并且要有详细的说明。
  原则1.3 在同一项目组或产品组内，调测打印的日志要有统一的规定。
  原则1.4 不能用断言来检查运行时错误。
  原则1.5 为单元测试和系统故障注入测试准备好方法和通道。

九、安全性

  原则1.1 对用户输入进行检查。
  原则1.2 确保所有字符串是以NULL结束。
  原则1.3 不要将边界不明确的字符串写到固定长度的数组中。
  原则1.4 避免整数溢出、避免符号错误和避免截断错误。
  原则1.5 确保格式字符和参数匹配
  原则1.6 避免将用户输入作为格式化字符串的一部分或者全部
  原则1.7 避免使用strlen()计算二进制数据的长度
  原则1.8 使用int类型变量来接受字符I/O函数的返回值
 

十、单元测试
  原则1.1 在编写代码的同时，或者编写代码前，编写单元测试用例验证软件设计/编码的正确。。
  原则1.2 单元测试关注单元的行为而不是实现，避免针对函数的测试。
  

十一、可移植性
  原则1.1 不能定义、重定义或取消定义标准库/平台中保留的标识符、宏和函数。
  原则1.2 不使用与硬件或操作系统关系很大的语句，而使用建议的标准语句，以提高软件的可移植性和可重用性。
  原则1.3 除非为了满足特殊需求，避免使用嵌入式汇编