C语言编程规范

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

文章标题:C语言编程规范

字数:1.8k

本文作者:Soaring Lee

发布时间:2020-08-16, 15:13:47

最后更新:2021-08-13, 23:02:32

原始链接:https://soaringleefighting.github.io/2020/08/16/【工程化系列】C语言编程规范/

版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。

×

喜欢就点赞,疼爱就打赏

相册