用 c++ 开发一款商业产品,需要哪些规范

最近开始接手项目组的开发管理工作,项目组开发的产品一期功能基本开发完成,进入内部测试及小渠道发布阶段,然而产品的稳定性还存在很大问题。

先做一下背景介绍,项目组开发的是一款面向C端的互联刚产品,运行操作系统为windows。整个项目使用c++开发,总体代码量大概在数十万行。

c++是一门很复杂的语言,有很多强大的特性,然而当用其开发一款商业产品时,这些特性可能会带来麻烦。所以当设计c++的使用规范时,更多的是对其做减法。

本文的规范针对VC++开发环境,开发工具为Visual Studio。

文件系统目录规范

一款完整的商业产品开发通常会涉及到很多模块,这其中包括可执行程序(.exe),项目组开发的库(静态库或动态库),第三方的库(静态库或动态库),测试程序,这么多的模块和代码,需要一个良好组织的目录结够。
这里假设项目名称为XXProject

  • XXProject
    • XXProject.sln
    • Bin
      • Debug
      • Release
    • TestBin
      • Debug
      • Release
    • Src
    • Document

其中Bin存放需要发布的可执行程序,TestBin存放测试程序的可执行文件,Src存放项目的工程文件和源代码,Document存放项目相关的开发文档(如项目说明,代码规范等)。

接下来假设项目包括如下工程:XXMain(发布的主程序),XXUpdate(升级程序),XXSdk(自己开发的基础库),XXThird(第三方库), XXTest(测试程序)

  • Src
    • XXMain
      • XXMain.vcxproy
      • code文件
    • XXUpdate
      • XXUpdate.vcxproy
      • code文件
    • XXTest
      • XXTest.vcxproy
      • code文件
    • XXSdk
      • XXSdk.vcxproy
      • code文件
    • ThirdLib
      • XXThird
    • Lib
      • Debug
      • Release
    • Include
      Lib库用来存放静态库,动态库的.a文件,Include用来存放公共头文件,ThirdLib用来存放第三方库。

解决方案目录规范

解决方案目录是VS开发工具提供的逻辑上组织项目的方式,与物理文件系统并不存在对应关系。
仍然假设项目包含上述项目和模块。

  • Solution (解决方案)
    • Application (解决方案文件夹)
      • XXMain (工程)
      • XXUpdate (工程)
    • Test (解决方案文件夹)
      • XXTest (工程)
    • Library (解决方案文件夹)
      • XXSdk
    • ThirdLibrary(解决方案文件夹)
      • XXThird
    • Public (解决方案文件夹)
      • 公共头文件

代码编写规范

1:禁用全局变量

全局变量会带来晦涩的依赖问题

2:禁用goto指令

goto指令的代码难以阅读和维护

3:禁用异常机制

c++的异常机制有很多缺陷且复杂

4:用struct封装数据,使用class定义对象

C++中class和struct几乎没有区别,在规范中进行语义的区分

5:struct和class必须显示包含构造函数
6:除非特殊情况,总是将析构函数定义为虚函数

方便继承时的资源释放

7:不要在构造函数中执行复杂操作,推荐加入init函数用于初始化操作

构造函数没有返回值,难以反馈错误

8:不要在构造函数中调用虚函数

构造函数中的虚函数不会重定向到子类。

9:慎用继承

相比对象组合,继承带来更强的依赖,推荐使用接口继承而不是对象继承

10:禁用多重继承(接口继承除外)

多重继承通常代表不好的设计

11:慎用运算符重载

运算符重载会混淆代码的语义,应只在不会造成混淆时使用

12:将成员设置为私有并提供访问函数

封装是降低代码耦合的有力武器

13:将同一访问权限的成员定义在一起

可以按照public,protect,private顺序进行组织

14:避免出现大而全的类

当一个类的代码超过1000行,应有所警惕,超过2000行,则应考虑拆分(行数不包括注释)

15:头文件应包含它所需要的头文件

这样可以保证cpp文件引入该头文件后不需要包含其它头文件

16:合理的组织引入的头文件,不要重复引入,不要引入不必要的头文件

可以以系统头文件,第三方库头文件,项目组库头文件,本程序头文件来组合,不同类型头文件之间用空格隔开

17:头文件使用# define宏来避免多重包含

pragma once 指令只有VC编译器能识别

18:允许合理的使用友元特性

19:使用引用传递对象类型参数, 对于不需要改变的参数加入const修饰符

引用传递可以避免对象拷贝

20:函数应该进参在前,出参在后

21:使用明确的返回值指示函数的运行结果,而不是用返回的内容来指示结果

推荐: int GetDeviceName(string& deviceName);
不推荐: string GetDeviceName()

22:声明基本类型变量后立即赋值

正确 int nCount = 0; bool bSuc = false; 错误 int nCount; bool bsuc;

23:使用内联,枚举,常量来代替宏

宏的使用有很多弊端,应尽量避免

24:使用singleton模式代替静态类

相比静态类,singleton模式可以更好地控制初始化时机。

25:使用share_ptr来管理指针

指针和管理在复杂项目中十分困难,使用智能指针是不二选择

26:使用weak_ptr来处理循环引用
27:明确对象或资源的生存周期

明确对象的生存周期通常代表着良好的设计

28:合理的使用缩进,空格

最重要的是保持风格的统一,自动生成的代码可能会打破这种统一,应该灵活设计规则

29:合理使用typedef缩减类型的长度,合理使用auto

使用stl时经常会导致过长的类型,合理使用auto可以有效减少代码长度

命名规则

由于是在VC环境下开发,沿用微软的命名驼峰命名法

选择哪种命名方式实际上不是很重要,最重要的是保持统一

  • 代码文件: DeviceMgr.h, DeviceMgr.cpp
  • 解决方案目录: NetLibrary
  • 工程筛选器: DataModel
  • 类:CDeviceMgr
  • 结构体: DeviceInfo
  • 变量: listDevice
  • 类成员: m_deviceName
  • 函数: GetName; GetDeviceName;
  • 代表bool含义的变量: 都以b开头,如:bOk, bSafe
  • 代表整数含义的变量: i表示符号整数,n表示无符号整数
  • 避免无意义的变量名和缩写: 如 x,dn(deviceName)等

注释规则

  • 文件注释:注明文件作者,联系方式,文件代码作用,重大修改记录等
  • 类注释:说明类的作用,使用限制等等
  • 函数注释: 尽量依靠意义明确的函数命名而不是依靠注释,说明函数的使用限制,对于意义不明确的参数加以说明
  • 变量注释:尽量依靠意义明确的变量命名而不是依靠注释,特殊情况。
  • 实现注释: 对于使用了非常规技巧,或复杂算法,或很复杂的业务逻辑部分要加入注释说明

原则: 注释应风格统一,简短而意义明确,最终目的是有效帮助其它人阅读和理解代码的目的

日志

日志的打印十分重要,是产品发生问题时重要的参考依据

  • 日志的打印要尽量详尽,合理划分日志等级,一般为Fatal, ERROR, WARNING, DEBUG, INFO
  • 统一使用unicode(utf-16)编码来输出日志
  • 提供异步打印日志的接口
  • 提供定期清理日志的机制
  • 在发布版中将日志等级设置为ERROR或更高,提供配置文件供调整日志等级

一些其它规则

  • 避免大而全的类(代码控制在1000行以内)
  • 避免过长的函数(代码控制在200行以内)
  • 避免深层的嵌套(不要超过3层)
  • 使用do-while-break技巧来避免重复写释放资源的代码
  • 尽量使用RALL技巧来释放资源
  • 当函数或代码废弃时,应与标注,最好将其注释掉并定期清理

线程和锁

复杂的项目肯定会涉及到多线程开发,而开发多线程程序是十分困难的。据我们统计,项目组产品有70%左右的崩溃和bug和线程有关。

将线程模块独立出来,交给项目最有经验的开发人员管理和维护,对外暴露抽象接口,屏蔽线程的概念。
强制使用RALL技术来使用锁

未尽
本文并没有涉及到C++规范的所有方面,欢迎讨论和补充

文/疯狂早茶

关键字:产品经理, 函数

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部