C++的一些编程规范

linyilong3

于 2018-09-06 16:26:00 发布

阅读量94

点赞数

本文链接：https://blog.csdn.net/linyilong3/article/details/100881257

版权

新规范的目标:

让代码排错更加简单
程序员专心于业务逻辑
将一些错误交给编译器处理
提高代码可维护性
逐步实现插件化

编码

使用array(QT下用QVarLengthArray)代替和vector代替原生数组，除非与外部库交互，否则不要直接操作内存(即暴露data的接口)

关于array和vector初始化麻烦的问题，在VS2010下使用boost::assign库，在VS2015下则使用list initial的语法

使用array和vector代替原生数组以后，可以很好找到越界的地方
尽量不要直接操作内存, 如果需要使用内存和字符串操作，尽量使用memset_s, memcpy_s,尽量使用_s结尾的函数

http://en.cppreference.com/w/c/string/byte

如果需要初始化数组，使用int a[COUNT] = {0}这种语法(但实际上尽量不要直接使用原生数组)
在进行memory操作的时候，需要使用is_pod验证下变量类型是否pod类型
使用STL的算法代替手写的算法，平常用到的算法STL里面或者QT的算法模块里面都有

http://en.cppreference.com/w/cpp/algorithm
构造函数一定要初始化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
1. 有一个问题，经常会掉线，因为网络有时候波动会比较大，写数据库会很慢，这个时候如果新客户端连上去后会发送所有的数据，将会导致心跳包处理不及时，客户端会主动断开，排查完原因后，在初始化发送数据的地方编写一段代码，当初始化超过一定的时间后，将会记录一个warning，下次发生这种情况，直接通过log来排查分析
2. 有时候一些模块因为需要排队处理数据，但是数据处理不即时，导致数据一直存储在buffer里面，但是按照正常情况下，不应该发生这种情况。排查完问题以后，应该在插入buffer的地方写一个判断代码，当buffer大于多少后，给出一个warning
底层数据管理类不要直接暴露内部的情况，并且将对底层数据操作的算法提取出来写在管理类里面，而不是大家都写一个相同的算法

在代码重构阶段，一旦底层数据直接暴露，那么将会很难修改

一旦代码有相关联的模块，这种方式比较好处理，比如删除元素，需要把相关联的数据都删除掉，如果没有把deleteTarget封装成一个接口，那么需要查找所有相关联的代码，把这个业务的代码再写一遍

防止大部分人写了相同的代码

所有数据只有一份，包括内存里面的数据和网络消息,现在一个数据结构经常定义了2-3份数据，包括内存里面的，序列化成网络消息的
组合，继承与接口设计

继承要保证是一个is-a的类型，即保证同样的逻辑操作可以用在同一个接口上面，而不需要进行大量的转换，如果逻辑操作出现大量的类型转换，考虑是否继承出现了问题
信号

将业务组合成一个函数，单独的功能写成一个单独的模块，然后在一个函数里面将这些业务组合起来
如果有大量相同的逻辑代码，考虑是否可以提取成一个函数或者模板, 特别是当一个逻辑不会增加依赖的时候
如果使用了大量的dynamic_cast，并且有相同逻辑的代码，考虑是否可以将这个行为抽象成一个接口