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、多行修改、新增采用包含性，前后呼应的成对注释
在本节中应着重说明系统的功能特性及其逻辑关系；避免对状态性和现状性的描述，并需重点阐述其线程同步机制
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），建议通过合理的程序结构安排使得整个流程最终均以返回指令结束
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、避免意料之外的死循环
在处理需要检测某个值的循环逻辑时，在大多数情况下并非必须一直保持循环状态。因此，在设计相关算法时应特别关注其终止条件，并确保不会出现意外导致无限循环的情况。例如，在判断等待时间和等待次数时
14、浮点型类型大小比较
14.1、浮点型不能直接比较大小一般用精度比较，精度在可接受范围内即可
15、参数缺省值规范
第 15.1 条不允许将 0 作为默认值；由于无法确定 0 是否被视为合法默认值还是被有意跳过（即人为忽略），从而导致必填字段未被设置。
15.2、参数载入内存的时候，必须进行初始值合法判断，最大、最小合法区间判断。
二、注释
1、总原则
注释是程序员对编写的程序、文件的说明。
注释用中文，少用散装英语注释，词不达意。
注释应该意思明了，简单易懂，多使用大白话，少用专业术语。
尽管编写注释的过程令人感到费力且耗时, 但对于提升代码的整体可读性至关重要. 这些规定明确了应如何标注以及标注的位置. 当然需要记住, 注释确实不可或缺. 然而, 代码本身就是最好的注释. 明确的类型和变量命名比通过注解来解释较为模糊的名字更加直观易懂.
2、文件注释
对于包含声明的C++代码及其实现部分，在头文檔中明確標示；若為單一文件，则置于其起始位置。
文件应该在文件开头加入以下注释：
/
// 描述:说明文件的功能。
// 作者：姓名
// 创建日期：
// 使用说明：使用简要说明
// 修改:修改者姓名，时间
// 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****
错误示例：AfxMessageBox("打开文件失败");
规范示例：AfxMessageBox("启动xx文件失败；可能是文件不存在或被其他程序占用而无法启动；建议您核实xx目录下的文件情况及其是否存在冲突使用情况");
- 示例2
错误示例：AfxMessageBox(_T("控制器未连接，下载参数失败"))
规范示例：AfxMessageBox(_T("控制器未连接导致参数下载失败；建议您逐一排查以下问题：首先检查xx控制卡的工作灯状态以及连接线是否存在异常；如果上述方法无法解决问题，请及时联系测试团队并由技术员使用第三方检测工具重新评估控制卡的状态。如前所述的方法仍无法解决问题，则应将此情况提交技术支持部门进行进一步诊断。"))
五、编译管理员身份运行程序
受win10系统权限管理控制的问题影响下, 导致出现诸如ttp板卡在备份日志文件时出现故障等现象; 针对上述问题, 特制定以下具体规定.
打印软件，配置UAC为管理员身份模式；
调度器软件，配置UAC为管理员身份模式。
操作如下：
