本文目录
1、参考
2、C语言编程规范
2.1 代码总体原则
- 1、清晰第一
- 2、简洁为美
- 3、选择合适的风格，与代码原有风格保持一致。
（1）一般情况下，代码的可阅读性高于性能，只有确定性能是瓶颈时，才应该主动优化。
（2）废弃的代码(没有被调用的函数和全局变量)要及时清除，重复代码应该尽可能提炼成函数。
（3）对于C语言来说，头文件的设计体现了大部分的系统设计。
2.2 （一）、头文件
原则1.1 头文件中适合放置接口的声明，但不适合放置实现。
原则1.2 头文件应当职责单一。
规则1.1 每一个.c文件应有一个同名.h文件，用于声明需要对外公开的接口。
规则1.2 禁止头文件循环依赖。
规则1.3 .c/.h文件禁止包含用不到的头文件。
规则1.4 头文件应当自包含。
规则1.5 总是编写内部#include保护符（#define 保护）。
#define SCM_ENCODE_H规则1.6 禁止在头文件中定义变量。
规则1.7 只能通过包含头文件的方式使用其他.c提供的接口，禁止在.c中通过extern的方式使用外部函数接口、变量。
2.3 （二）、函数
函数设计的精髓：编写整洁函数，同时把代码有效组织起来。
原则2.1 一个函数仅完成一件功能。
原则2.2 重复代码应该尽可能提炼成函数。
规则2.1 避免函数过长，新增函数不超过50行（非空非注释行）。
规则2.2 避免函数的代码块嵌套过深，新增函数的代码块嵌套不超过4层。
规则2.3 可重入函数应避免使用共享变量（全局变量或静态变量）；若需要使用，则应通过互斥手段（关中断、信号量）对其加以保护。
规则2.4 对参数的合法性检查，由调用者负责还是由接口函数负责，应在项目组/模块内应统一规定。缺省由调用者负责。对函数的错误返回码要全面处理。（错误返回机制）
规则2.6 设计高扇入，合理扇出（小于7）的函数。
规则2.7 废弃代码（没有被调用的函数和变量)要及时清除。
2.4 （三）、标识符 命名与定义
不建议采用匈牙利命名法（前缀_基本类型_限定词）。
规则3.1 产品/项目组内部应保持统一的命名风格。
b 全局变量应增加“g_”前缀。
规则3.3 静态变量应增加“s_”前缀。Mgpast/sz
规则3.4 对于数值或者字符串等等常量的定义，建议采用全大写字母，单词之间加下划线\„_\‟的方式命名（枚举同样建议使用此方式定义）。
建议3.5 重构/修改部分代码时，应保持和原有代码的命名风格一致。
建议3.6 文件命名统一采用小写字符。
建议3.7 不建议使用匈牙利命名法。
使用名词或者形容词＋名词方式命名变量。
建议3.9 函数命名应以函数要执行的动作命名，一般采用动词或者动词＋名词的结构。
2.5 （四）、变量
规则4.1 防止局部变量与全局变量同名。
规则4.2 通讯过程中使用的结构，必须注意字节序。
规则4.3 严禁使用未经初始化的变量作为右值。所有变量定义时必须初始化。
建议4.1 在首次使用前初始化变量，初始化的地方离使用的地方越近越好。
建议4.2 尽量减少没有必要的数据类型默认转换与强制转换。
2.6 （五）、宏、常量
规则5.1 用宏定义表达式时，要使用完备的括号。
规则5.2 将宏所定义的多条表达式放在大括号中。（更好的方法是多条语句写成do while(0)的方式）
规则5.3 使用宏时，不允许参数发生变化。
规则5.4 不允许直接使用魔鬼数字。MAGIC NUMBER
建议5.1 常量建议使用const定义代替宏。
建议5.2 宏定义中尽量不使用return、goto、continue、break等改变程序流程的语句。
规则6.5 所有的if … else if结构应该由else子句结束 ；switch语句必须有default分支。
建议6.2 if语句尽量加上else分支，对没有else分支的语句要小心对待。
建议6.3 不要滥用goto语句。
建议7.1 将不变条件的计算移到循环体外。
建议7.4 将多次被调用的 “小函数”改为inline函数或者宏实现。
2.7 （六）、注释
原则8.1 优秀的代码可以自我解释，不通过注释即可轻易读懂。建议 /* /
*原则8.2** 注释的内容要清楚、明了，含义准确，防止注释二义性。
原则8.3 在代码的功能、意图层次上进行注释，即注释解释代码难以直接表达的意图，而不是重复描述代码。
规则8.1 修改代码时，维护代码周边的所有注释，以保证注释与代码的一致性。不再有用的注释要删除。
规则8.2 文件头部应进行注释，注释必须列出：版权说明、版本号、生成日期、作者姓名、工号、内容、功能说明、与其它文件的关系、修改日志等，头文件的注释中还应有函数功能简要说明。
2.8 （七）、排版与格式
规则9.1 程序块采用缩进风格编写，每级缩进为4个空格。
规则9.2 相对独立的程序块之间、变量说明之后必须加空行。
规则9.3 一条语句不能过长，如不能拆分需要分行写。一行到底多少字符换行比较合适，产品可以自行确定。
规则9.4 多个短语句（包括赋值语句）不允许写在同一行内，即一行只写一条语句。
规则9.6 在两个以上的关键字、变量、常量进行对等操作时，它们之间的操作符之前、之后或者前后要加空格；进行非对等操作时，如果是关系密切的立即操作符（如－>），后不应加空格。（“松散方式”）
2.9 （八）、安全性
原则13.1 对用户输入进行检查。
规则13.1 确保所有字符串是以NULL结束。
———————————–THE END!——————————
本博文只能阅读，谢绝转载，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 2963033731@qq.com
