C++编程规范

一、重点禁忌

1、日志记录

1.1、日志必须分等级：CRASH、ERROR、WARN、TIP、INFO

1.2、CRASH、ERROR、WARN三个级别异常必须有日志记录

1.3、非预期结果、必须日志

2、高技巧语句

2.1、高技巧语句不等于高效率的程序，不要使用难懂的技巧性很高的语句，除非很有必要。

2.2、高技巧语句，通常难懂，可读性差，在可读性和程序效率上进行权衡时，应该更多考虑可读性。

3、递归

3.1、递归尽量不要使用，难懂，效率低。

4、代码注释

4.1、多行修改、新增采用包含性，前后呼应的成对注释

4.2、应进行功能性，逻辑性描述，少进性状态性、现状性描述；涉及到业务逻辑跳转线程同步要详细描述。

5、三目运算符

5.1、三目运算符，不利于理解，不利于调试，降低代码可读性；统一使用if-else代替

5.2 、简单逻辑判断允许使用，如int nResult = bGet ? 2 : 1;

6、资源的获取与释放

6.1、 new/delete, malloc/free, lock/unlock等操作，尽量做到成对使用，即获取与释放资源是对应的。通过好的结构设计，减少隐患。

7、函数出口

7.1、函数的出口，在没有进入主体功能之前，可以进行简明的return操作

7.2 、代码进入主体功能块后，禁止随意return，尽量通过逻辑结构设计，运行都最后return

8、函数入口

8.1、函数入口，需要做形参的合法判断，不合法直接返回。

8.2、入口判断前，禁止进行功能代码编写

8.3 、入口判断，逻辑要简明，禁止嵌套

9、if-else使用

9.1、各种可能要全面，用else时需要逻辑严谨，可能包含你预期之外的情况。

9.2、当else不存在时，也要写，逻辑严谨，可读性强。

10、缩进问题

10.1、大括号的嵌套，建议不要超过三层。

10.2、多层嵌套可读性差，设计不合理

11、函数代码行数

11.1、建议控制在一、二屏之内

11.2、禁止函数行数超过三屏

11.3、如果多重缩进，多重嵌套，建议拆封成子函数

12、文件与类的关系

12.1、原则上一个文件只包含一个类

13、避免意料之外的死循环

13.1、对于需要循环检测某个值的逻辑，除了某些明确需要一直循环的情况外，要特别注意循环退出条件，检测会不会引起意料之外的死循环。如判断等待时间，或者等待次数。

14、浮点型类型大小比较

14.1、浮点型不能直接比较大小一般用精度比较，精度在可接受范围内即可

15、参数缺省值规范

15.1、0不能作为缺省值，因为0无法判断是合法默认值，还是人为忽略，导致必填项没有设置。

15.2、参数载入内存的时候，必须进行初始值合法判断，最大、最小合法区间判断。

二、注释

1、总原则

注释是程序员对编写的程序、文件的说明。

注释用中文，少用散装英语注释，词不达意。

注释应该意思明了，简单易懂，多使用大白话，少用专业术语。

注释虽然写起来很痛苦，但对保证代码可读性至关重要，下面的规则描述了应该注释什么、注释在哪儿。当然也要记住，注释的确很重要，但代码本身就是最好的注释，类型和变量命名意义明确要比通过注释解释模糊的命名好得多。

2、文件注释

对有声明文件(头文件)和实现文件(cpp文件)的，把文件说明写在头文件开头。只有单文件的，写在单文件开头。

文件应该在文件开头加入以下注释：

/

// 描述:说明文件的功能。

// 作者：姓名

// 创建日期：

// 使用说明：使用简要说明

// 修改:修改者姓名，时间

//    1.修改内容1

//    2.修改内容2

// 修改:修改者姓名，时间

//    1.修改内容1

//    2.修改内容2

/

为了头文件被重复包含要求对头文件进行定义如下:

#ifndef __GUID_H__

#define __GUID_H__

其中GUID为工作生成的GUID,VS中有工具可点击生成。

3、类注释

归为文件注释，一个文件建议只包含一个类，所以在文件头中，对类的功能需要进行说明

4、函数注释

对于函数，应该从“功能”，“参数”，“返回值”、“主要思路”、“调用方法”、“日期”六个方面用如下格式注释：

//

// 功能： 从一个字符串中删除一串字符

// 参数：

// （InOut） sSrc: 原来字符串指针

// （InOut） nSrcLen: 输入sSrc指向的缓存中，字符的字节数，输入修改后的字节数

// （Out）   sDel: 用于装载删除的字符串内容的缓存指针。

// （InOut） nSrcLen: 输入sDel缓存大小，输入删除的字符串的字节数

// 返回： 成功返回true，或者false。（对返回值有错误编码的要求列出错误编码）。

// 调用方法：......

// 主要思路：本算法主要采用循环比较的方法来从strByDelete中找到

// 与strToDelete相匹配的字符串，对多匹配strByDelete

// 中有多个strToDelete子串）的情况没有处理。请参阅：

bool DeleteSubStr(char* sSrc, int& nSrcLen, char* sDel, int& nDelLen);

5、变量注释

通常变量名本身足以很好说明变量用途，特定情况下，需要额外注释说明。

类数据成员：每个类数据成员（也叫实例变量或成员变量）应注释说明用途，如果变量可以接受NULL 或-1等警戒值（sentinel values），须说明之，如：

//记录表中记录总数，初始为-1

int m_nNubTotalEntries;

6、代码注释

三、命名规则

命名规则设置，原则上，不易过繁，以易使用，易实行，同时能规范编码为宗旨。

1、变量命名规则

变量命名由三部分要素，即属性、类型、描述

排列顺序从左到右：属性(小写)_类型(小写)描述(首字母大写)

全局变量，类成员变量要求包含三要素

局部变量，临时变量包含类型、描述两个要素

声明时即初始化

避免短的或无意义的命名

当一个变量被用到时再声明它

声明每一个变量都要用独立的一行

单个字符的变量名只适用于计数的临时变量

1.1、属性部分

全局变量 g_

常量 c_

静态变量 s_

类成员变量 m_

当一个常量或者静态变量隶属于类时，优先级从上而下，即类的静态变量属性应该为s_而非m_。

1.2、类型部分

整型 n

浮点型 f

双精度泛点型 d

字符串 s

布尔 b

指针 p

函数 fn

1.3、描述部分

最大 Max

最小 Min

初始化 Init

源对象 Src

目的对象 Des

取值：Get

设置：Set

增加：Add

删除：Del

1.4、命名规则

 // 正确示例

 int nHeight = 0;

 char *pNameOfThis = NULL;

 bool bSuccess = false;

 static int s_nCount = 0;

2、函数命名规则

采用驼峰命名法

以动词+名词或者动词+形容词+名词结构命令

首字母必须大写

如：GetSum, SetParam, ConnectDB, GetLastPoint

3、类命名规则

采用驼峰命名法

类名以大写字母开头

所有类名以Jx开头，后面跟模块名，接着功能名。

模块首字母必须大写

如JxPrinterApp,表示Printer模块的application功能函数。

4、文件命名规则

原则上一个cpp文件只包含一个类

文件名同类名保持一致，便于阅读。

如果同一个文件包含多个实现类，文件名以主要功能类命名。

四、异常日志规范

异常信息格式：“怎么了；[为什么；]怎么办；”。

提示信息、警告信息、错误信息实质目的是告知使用者“怎么办”的，也就是指导他人具体如何解决问题的，所以，完整的日志信息应该即要告知“怎么了”，也要说明“为什么”，更要指示“怎么办”。

所以所有警告级别以上的日志、弹窗等形式表现的信息，都尽量包含“怎么了；为什么；怎么办”三部分信息。有时候并不能解释“为什么”，作为开发者也必须给出两部分信息，状态描述“怎么了”与明确的指导性意见“怎么办”，即使指导性意见不能彻底解决问题。举例如下：

1. 示例1

错误示例：AfxMessageBox("打开文件失败");

规范示例：AfxMessageBox("打开xx文件失败；可能文件不存在或被其他软件独占打开；请检查xx目录下，xx文件是否存在，或是否被其他软件打开");

1. 示例2

错误示例：AfxMessageBox(_T("控制器未连接，下载参数失败"))

规范示例：AfxMessageBox(_T("控制器未连接，下载参数失败；请检查xx控制卡工作灯是否正常，连接线是否正常，然后重试。如果以上方法不能恢复，请联系测试部，让测试工程师远程指导用第三方工具检测控制卡是否正常"))

五、编译管理员身份运行程序

由于win10系统权限管理控制问题，引出一些如：ttp板卡备份日志文件失败等问题；现特规范如下：

打印软件，配置UAC为管理员身份模式；

调度器软件，配置UAC为管理员身份模式。

操作如下：