C++的一些编程规范
新规范的目标:
- 让代码排错更加简单
- 程序员专心于业务逻辑
- 将一些错误交给编译器处理
- 提高代码可维护性
- 逐步实现插件化
编码
-
使用array(QT下用QVarLengthArray)代替和vector代替原生数组,除非与外部库交互,否则不要直接操作内存(即暴露data的接口)
关于array和vector初始化麻烦的问题,在VS2010下使用boost::assign库,在VS2015下则使用list initial的语法
使用array和vector代替原生数组以后,可以很好找到越界的地方
-
尽量不要直接操作内存, 如果需要使用内存和字符串操作,尽量使用memset_s, memcpy_s,尽量使用_s结尾的函数
如果需要初始化数组,使用int a[COUNT] = {0}这种语法(但实际上尽量不要直接使用原生数组)
-
在进行memory操作的时候,需要使用is_pod验证下变量类型是否pod类型
-
使用STL的算法代替手写的算法,平常用到的算法STL里面或者QT的算法模块里面都有
-
构造函数一定要初始化C原生类型的数据成员
-
使用C++风格的转换,不要用C语言方式的转换
dynamic_cast,当继承树不一样的时候,编译器将会报错,或者转换失败,原生的C语言编译正确并且转换正确
static_cast,会有转换类型检查,比如子类往父类强转,编译期检查
-
使用QVariant代替void*
当进行强转错误的时候,QVariant能直接返回错误的数值
-
使用强枚举
便于查看代码
如果传入错误,可以直接让编译器报错
-
编写测试,系统检测架构图,然后 将测试用例自动化
-
分离数据和界面
-
常用的宏定义,放在Global里面,类似于qt_global文件
IOCEAN里面经常会有重复的宏定义,比如PI,比如无效的HDG,需要防止这种情况
-
多用const
const的类成员函数,告诉使用者这个函数将不会对类成员进行改变,在写代码如果有改变,也能直接报错
const的参数
const的引用参数
在计算出一些临时的参数后,如果确定这个参数不会再改变了,也建议用const
-
使用Q_ASSERT, assert, static_assert断言处理逻辑上不可能出现的情况
如果已经使用Q_ASSERT,表示这种情况下不需要测试
在发送网络的数据的时候,有时候发送的是纯二进制数据,但是后续用户可能会在这个数据加入非POD数据,可以使用static_assert( std::is_pod<>::value) 来确保这个结构体是纯二进制数据
-
字符串和数据结构库统一使用QT的库,比如QLIST,QVector,而非std::list,std::vector
为了防止混用
与QT库比较好结合
- 信号连接使用QT5的新语法
资源管理
-
使用scoped_pointer和shared_pointer来代替原始指针
专注业务编写,而非内存管理以及排错
便于调试,如果是局部变量的指针,在release会直接被优化成地址,无法显示信息,如果是shared_pointer或者scoped_pointer则不会
-
所有创建的线程,都要设置名称,方便查询线程的用处
-
资源应该遵循谁申请谁释放的原则,不应该把一个资源胡乱传递(将会导致最后资源不知道谁释放谁持有)
- 如果资源需要转移,尽量使用MOVE来进行转移,然后用RAII来释放
-
CPP里面的模块变量使用static const而不是只有const声明
-
使用static const代替宏定义
代码结构
-
记录log,log不仅仅是开发的时候调试使用,更是在用户机子上分析错误的重要工具,现在我们大部分的log都是维持在debug级别,应该要多编写warning和error级别的log
由于很多情况下,一些错误的情况无法复现,也无法分析,特别在部署到用户机子上以后,很难到现场排查
一开始不一定要记录log,根据自己的经验判断是否需要log,但是随着开发进度的增加,会出现一些莫名其妙的错误,比如网络不稳定,内存不稳定导致问题,排查完问题后,在发生问题的根源记录下log
-
有一个问题,经常会掉线,因为网络有时候波动会比较大,写数据库会很慢,这个时候如果新客户端连上去后会发送所有的数据,将会导致心跳包处理不及时,客户端会主动断开,排查完原因后,在初始化发送数据的地方编写一段代码,当初始化超过一定的时间后,将会记录一个warning,下次发生这种情况,直接通过log来排查分析
-
有时候一些模块因为需要排队处理数据,但是数据处理不即时,导致数据一直存储在buffer里面,但是按照正常情况下,不应该发生这种情况。排查完问题以后,应该在插入buffer的地方写一个判断代码,当buffer大于多少后,给出一个warning
-
-
底层数据管理类不要直接暴露内部的情况,并且将对底层数据操作的算法提取出来写在管理类里面,而不是大家都写一个相同的算法
在代码重构阶段,一旦底层数据直接暴露,那么将会很难修改
一旦代码有相关联的模块,这种方式比较好处理,比如删除元素,需要把相关联的数据都删除掉,如果没有把deleteTarget封装成一个接口,那么需要查找所有相关联的代码,把这个业务的代码再写一遍
防止大部分人写了相同的代码
-
所有数据只有一份,包括内存里面的数据和网络消息,现在一个数据结构经常定义了2-3份数据,包括内存里面的,序列化成网络消息的
-
组合,继承与接口设计
继承要保证是一个is-a的类型,即保证同样的逻辑操作可以用在同一个接口上面,而不需要进行大量的转换,如果逻辑操作出现大量的类型转换,考虑是否继承出现了问题
-
信号
将业务组合成一个函数,单独的功能写成一个单独的模块,然后在一个函数里面将这些业务组合起来
-
如果有大量相同的逻辑代码,考虑是否可以提取成一个函数或者模板, 特别是当一个逻辑不会增加依赖的时候
-
如果使用了大量的dynamic_cast,并且有相同逻辑的代码,考虑是否可以将这个行为抽象成一个接口
工程方案
-
通用的库弄成一个lib,比如SQL之类的库
-
非通用的库,但是一些项目里面要用到的,新建一个解决方案,解决方案里面有一个共用的库
待议
多线程,openmp, map-reduce模式
- 语义明确的多线程
-
SQL模块 select(tablename).where("i < 7").and("j > 8").or("x < 2")
-
使用std::function代理SIGNAL和SLOT的绑定
-
将不需要制作成索引的数据使用json保存,而不是另外创建一个表然后关联过去
-
尽量使用designer进行布局
所有人需要了解的C++技术
-
C++11
-
RAII
-
Move语义