版本开发中项目、工程与代码规范

来源：http://blog.csdn.net/lezhiyong
自用备忘与总结用，持续添加.....

 
一、代码规范：

1、 用typedef定义统一的类型，只使用定义好的类型如：int8_x，uint8_x ，int16_x ，uint16_x，int32_x，uint32_x，float32_x，float64_x，int64_x，uint64_x类型可满足项目的开发（x表示特定标识符）。详细参见《 规范工程中c/c++变量类型的定义》：点击打开链接

2、表达size的变量不要 size_t、int ，unsigned int 混用， 可统一使用size_t或 unsigned int（uint32_x）表述
    一方面可以防止类型转换时候的数据改变，二可以根据代码中的uint32和int32的定义清楚了解作者的意图。
案例：编译中出现:warning C4018: '>' : signed/unsigned mismatch
                             conversion from 'size_t' to 'int', possible loss of data
3、lib库的包含：要么在vs 的 工程属性->linker->input和c++->genneral定义用相对路径表述的库和头文件位置，要么在接口头文件中用  相对路径include头文件和lib库。不要两者混用，建议使用第一种方式，第二种方式对项目各工程文件的文件夹的层次结构有要求，否则包含时很容易出现 编译link报错：找不到某lib库。
4、对外接口中的结构体、类名、函数名命名同样命令风格.

案例：函数参数顺序中是先输入参数还是先输出参数的问题，特别是接口头文件中不要出现多种风格，造成调用者传参失误或阅读困难。
5、windows函数使用UNICODE字符串函数，自win NT起，windows所有版本都是完全使用unicode来构建，如果传入的是ANSI字符，windows系统也会转换为UNICODE,这些转换会产生时间和内存开销。

二、工程规范：
1、建立“通用底层库”提供通用的操作函数，如安全字符串拷贝，文件路径处理、时间处理、数字处理、字符串处理、通用宏SAFE_DELET  SAFE_RELEASE等供整个项目使用，团队成员都通过“通用库”加入函数和使用函数，不要在各自工程内重复造轮子或私自造轮子。
2、分类各个头文件及其内容的定义
有些头文件是模块提供的对外接口（需要与lib、dll配合使用），不同模块的头文件中放对应的内容，模块间的接口头文件内容不要交叉。
有些头文件是一些模块的宏定义和类型声明（不带cpp），声明与定义数量多时候，尽量分类成几个头文件如：
typesDef.h  提供基本数据类型定义；macroDef.h 提供通用宏定义、inline函数；buildDef.h  提供编译不同版本的宏定义；videoDef.h提供 视频模块的videoformat videosize 等结构体类型和宏定义;netDef.h定义网络发送接收信令的ID与信令结构体

案例1：***ccom.h本来是用来定义com组件接口的头文件，却被某不熟悉规则的工程师在该头文件中定义了很多RC资源ID，并在各ui模块的resource.h中被包含，后来***ccom.h定义的一个组件接口需要增加一个函数，该函数使用了一个在 ***def.h定义的类型，于是在***ccom.hinclude了***Mediadef.h，这种做法本来没什么问题，但导致各ui模块编译时候出现找不到***Mediadef.h的错误。本来不耦合的com组件模块和ui模块因为头文件内容交叉被关联到一起，并且***ccom.h头文件的修改导致其他功能不相关的模块也需要重编译。

3、代码与项目文件管理，建立层次与权限清晰的文件夹结构。
案例：开发文档与代码的文件夹管理问题：有的倾向代码模块内部创建一个文件夹存放该模块相关的开发设计文档，认为文档与代码查阅方便，而且权限好设置，具备该模块权限就能看到相应文档。另外一种是与项目代码文件夹并列建立一个文档文件夹，完全与代码分开，个人觉得完全分开好好点，1、方便代码管理如持续集成下的更新检测、代码下载与打包，2、与代码相比，文档是更重要的核心资产，需要区分对待 ，2、分开放权限控制虽然复杂一些，但也可以一样做好.
 

三、 项目规范
1、开发阶段需求、编码、用例与迭代的对接
2、版本验证阶段，开发与测试的对接
3、版本发布阶段，开发与测试的对接
数据流程：需求加入流程、问题单走单流程
内部管理：代码版本管理（迭代开发与svn分支）、激励制度
部门流程：测试与开发与系统
流程推动制度：问题单电子流、需求电子流、持续集成、责任人负责与推动