代码规范
- 程序的版式
1.1.程序块要采用缩进风格编写,缩进的空格数为 4个。
说明:
由开发工具自动生成的代码可能不一致,但如果开发工具可以配置,则应该统一配置缩进为4个空格
1.2.规则:缩进或者对齐只能使用空格键,不可使用 TAB 键.
说明:
使用TAB键需要设置 TAB 键的空格数目是4格
- 1.3.相对独立的程序块之间、变量说明之后必须加空行说明:
以下情况应该是用空行分开:
1)函数之间应该用空行分开:
2)变量声明应尽可能靠近第一次使用处,避免一次性声明一组没有马上使用的变量;
3)用空行将代码按照逻辑片断划分;
4)每个类声明之后应该加入空格同其他代码分开。
1.4. 较长的语句(>80 字符) 要分成多行书写
说明:
以下情况应分多行书写:
1) 长表达式要在低优先级操作符处划分新行,操作符放在新行之首,划分出的新行要进行适当的缩进,使排版整齐,语句可读。
2) 若函数或过程中的参数较长,则要进行适当的划分。
3) 循环、判断等语句中若有较长的表达式或语句,则要进行适应的划分,长表达式要在低优先级操作符处划分新行,操作符放在新行之首。
- 1.5. 不允许把多个短语句写在一行中,即一行只写一条语句。
说明:
一行代码只做一件事情,如只定义一个变量,或只写一条语句。这样的代码容易阅读,并且方便于写注释
- 1.6. if、for、do、while、case、switch、default 等语句自占一行,且if、for、do、while 等语句的执行语句部分无论多少都要加括号。
- 1.7. 代码行之内应该留有适当的空格说明:
采用这种松散方式编写代码的目的是使代码更加清晰。代码行内应该适当的使用空格,
具体如下:
1)关键字之后要留空格。象const、virtual、inline、case 等关键字之后至少要留一个空格, 否则无法辨析关键字。象 if、for、while 等关键字之后应留一个空格再跟左括号“(,,以突出关键字
2)函数名之后不要留空格, 紧跟左括号’(’, 以与关键字区别。
3)‘(’向后紧跟,‘)’,‘、’,‘;’向前紧跟,紧跟处不留空格。
4)‘,’之后要留空格,如 Function(x,y,z)。如果“;’ 不是一行的结束符号,其后也要留空格,如for (initialiazation; condition; update)
5)值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符,如“=”,“+=”,“>=”,“<=”,“+”,“*”,“%”,“&&”,“||”,“<<”,“^”,等二元操作符的前后应该加空格
6)一元操作符如“!”,“~”,“++”,“--”,“&”前后不加空格
7)像“[]”,“.”,“->”这类操作符前后不加空格
建议:
程序块的分界符(如 C/C++语言的大括号‘{’和‘}’应各独占一行并且位于同一列,同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义枚举的定义以及 if、for、do、while、switch、case 语句中的程序都要采用如上的缩进方式。
2、注释
2.1. 源文件头部应进行注释,列出:生成日期、作者、模块目的/功能等。
2.2. 函数头部应进行注释,列出: 函数的目的/功能、输入参数、输出参数、返回值等。
- 2.3. 注释应该和代码同时更新,不再有用的注释要删除。
- 2.4. 注释的内容要清楚、明了,不能有二义性。
- 2.5. 避免在注释中使用非常用的缩写或者术语
- 2.6. 注释的主要目的应该是解释为什么这么做,而不是正在做什么。如果从上下文不容易看出作者的目的,说明程序的可读性本身存在比较大的问题,应考虑对其重构。
- 2.7. 避免非必要的注释。
- 2.8. 注释的版式
- 说明:
- (1)注释也需要与代码一样整齐排版注释应与其描述的代码相近,对代码的注释应放在其上方或右方 (对单条语句的注释) 相邻位置,不可放在下面,如放于上方则需与其上面的代码用空行隔开。
- (2)注释与所描述内容进行同样的缩进。
- (3)将注释与其上面的代码用空行隔开
- (4)变量、常量、宏的注释应放在其上方相邻位置或右方。
- 2.9. 对于所有有物理含义的变量、常量,如果其命名不是充分自注释的,在声明时都必须加以注释,说明其物理含义
- 2.10. 数据结构声明(包括数组、结构、类、枚举等,如果其命名不是充分自注释的,必须加以注释。对数据结构的注释应放在其上方相邻位置,不可放在下面;对结构中的每个域的注释可放在此域的右方。
- 2.11. 对重要变量的定义需编写注释,特别是全局变量,更应有较详细的注释,包括对其功能、取值范围、以及存取时注意事项等的说明。
- 2.12.分支语句(条件分支、循环语句等)需编写注释
- 说明:
- 这些语句往往是程序实现某一特定功能的关键,对于维护人员来说,良好的注释帮助更好的理解程序,有时甚至优于看设计文档。
- 2.13. 注释不宜过多,也不能太少,源程序中有效注释量控制在 20%~30%之间
- 说明:
- 注释是对代码的“提示”,而不是文档,不可喧宾夺主,注释太多会让人眼花缭乱。
3. 标识符命名
3.1. 规则:
命名尽量使用英文单词,力求简单清楚,避免使用引起误解的词汇和模糊的缩写,使人产生误解说明:
较短的单词可通过去掉“元音”形成缩写;较长的单词可取单词的头几个字母形成缩写;一些单词有大家公认的缩写。
3.2. 规则:命名规范必须与所使用的系统风格保持一致,并在同一项目中统一说明:
(1)如在UNIX 系统,可采用全小写加下划线的风格或大小写混排的方式,但不能使用大小写与下划线混排的方式。
(2)用作特殊标识如标识成员变量或全局变量的 m_和 g_,其后加上大小写混排的方式是允许的。
3.3. 规则:
常量、宏和模板名采用全大写的方式, 每个单词间用下划线分隔。
3.4. 建议:
枚举类型enum 常量应以大写字母开头或全部大写
3.5. 建议:
命名中若使用了特殊约定或缩写,则要有注释说明
(1)应该在源文件的开始之处,对文件中所使用的缩写或约定,特别是特殊的缩写,进行必要的注释说明
(2)规则:自己特有的命名风格,要自始至终保持一致,不可来回变化
说明:
个人的命名风格,在符合所在项目组或产品组的命名规则的前提下,才可使用。(即命名规则中没有规定到的地方才可有个人命名风格)。
3.6. 规则:对于变量命名,禁止取单个字符 (如 i、j、k...),建议除了要有具体含义外,还能表明其变量类型、数据类型等,但 i、j、k 作局部循环变量是允许的。
说明:
变量,尤其是局部变量,如果用单个字符表示,很容易敲错(如 i 写成),而编译时又检查不出来,有可能为了这个小小的错误而花费大量的查错时间。
3.7. 建议:除非必要,不要用数字或较奇怪的字符来定义标识符。
3.8. 函数名以大写字母开头,采用谓-宾结构 (动-名),且应反映函数执行什么操作以及返回什么内容。
说明:
函数在表达式中使用,通常用于 f 子句,因此它们的意图应一目了然。示例:
不好的命名: if(CheckSize(x))
没有帮助作用,因为它没有告诉我们 CheckSize 是在出错时返回 true 还是在不出错时返回 true。
好的命名: if(ValidSize(x))
则使函数的意图很明确。
3.9. 建议:类、结构、联合、枚举的命名须分别以 C、S、U、E 开头,其他部分遵从一般变量命名规范。
4、可读性
4.1. 规则:用括号明确表达式的操作顺序,避免使用默认优先级。
4.2. 不要编写太复杂、多用途的复合表达式
4.3. 设计物理状态或者含有物理意义的常量,避免直接使用数字,必须用有意义的枚举或者常量来代替。
5、变量、结构
5.1. 尽量少使用全局变量,尽量去掉没必要的公共变量
说明:
公共变量是增大模块间耦合的原因之一,故应减少没必要的公共变量以降低模块建的耦合度。
5.2. 变量,特别是指针变量,被创建之后应当及时把他们初始化,以防止把未被初始化的变量稻城右值使用。
5.3. 仔细设计结构中元素的元素的布局与排列顺序,使结构容易理解,节省占用空间,并减少引起误用现象。
5.4. 留心具体语言及编译器处理不同数据类型的原则及有关细节。
说明:
如在C语言中,static 局部变量将在内存“数据区”中生成,而非 static 局部变量将在“堆栈”中生成。这些细节对程序质量的保证非常重要。
5.5. 尽量减少没有必要的数据类型默认转换与强制转换。
5.6. 当声明用于分布式环境或不同 CPU 间通信环境的数据结构时,必须考虑机器的字节顺序、使用的位域及字节对齐等问题。
6、函数、过程
6.1. 调用函数要检查所有可能的返回情况,不应该的返回情况要用 ASSERT 来确认。
6.2. 编写可重入函数时,应注意局部变量的使用(如编写 C/++语言的可重入函数时,应使用 auto即缺省态局部变量或寄存器变量)。
说明:
编写 C/C++语言的可重入函数时,不应使用 static 局部变量,否则必须经过特殊处理,才能使函数具有可重入性。
6.3. 调用公共接口函数时,调用者有保障调用参数符合要求的义务。作为一种防御性的编程风格,被调用函数也应该对传入参数做必要的安全检查。
6.4. 函数的规模尽量限制在100行以内
6.5. 一个函数仅完成一件功能
说明:
多功能基于一身的函数,很可能使函数的理解、测试、维护等变得困难。
6.6. 不能用ASSERT代替必要的安全处理代码,确保发布版的程序也能够合理地处理异常情况。
6.7. 尽量写类的构造、拷贝构造、析构和赋值函数,而不是用系统缺省的。
6.8. 对不需要拷贝构造函数时,应显式地禁止它,避免编译器生成默认的拷贝构造函数。
6.9. 谨慎使用与程序运行的环境相关的系统函数。
6.10. 禁止编写依赖于其他函数内部实现的函数。
6.11. 检查函数所有参数与非参数的有效性。
6.12. 函数实现中不改变内容的参数要定义成const。
6.13. 函数的返回值要清楚、明了,让使用者不容易忽视错误情况。