软件开发编码规范总结

1. 一个软件的生命周期中，80%的花费在于维护，代码规范降低了金钱成本和时间成本；
2. 几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护，代码规范减少了工作交接过程中的交流成本。
3. 规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的设计和代码，节约了时间，提高了工作效率。
4. 良好的编码规范可以有效避免一些低级错误，赢得同事的夸奖和上司的认可。

1.统一规范，方便阅读、维护，提高代码质量
2. 统一格式，使代码度量更加精确，为公司软件过程体系优化打好基础，为后续交接工作提供依据。

一、命名规范

• 名字应该能够标识事物的特性，并且与业务挂钩。
• 名字一律使用英文单词，而不能为拼音。
• 名字可以有两个或三个单词组成，但不应多于4个，控制在3至30个字母以内。
• 命名避免和关键字冲突
• 方法名、参数名、字段和变量统一使用Camel命名法，除首字母外，其他单词的首字母大写，剩余字母小写。
• 枚举、属性、类名和委托统一使用Pascal命名法，所有单词首字母都大写。
• 常量禁止缩写，采用完整大写

二、注释原则

• 一般情况下，源程序的有效注释量必须在30%以上。
• 避免使用装饰性内容，保持注释的简洁。
• 注释信息不仅要包括代码的功能，还应给出原因，不要为注释而注释。
• 除变量定义等较短语句的注释可用行尾注释外，其他注释当避免使用行尾注释。
• 注释不能嵌套
• 生成开发文档的需要用中文编写
• 如果需要注释的内容太多，需附加文档进行说明， 注释时加上”参见《****》”
• 距离较远的}必须注释
• 复杂的分支流程必须注释
• 代码质量不高但能正常运行，或者还没有实现的代码用//TODO:声明
• 存在错误隐患的代码用//FIXME:声明

三、编码风格规则

• 代码未写，文档先行，注释必须按照固定统一范式撰写。
• 关系运算必须常量在左、变量在右。
• 不许使用复杂的运算表达式，必要时添加括 而不依赖于优先级。
• 魔鬼数字需用宏定义替代。
• 局部变量必须初定义、避免不必要的内存操作、内存操作必须考虑异常处理

四、版本管理规则
        项目中，每个任务在完成一个稳定的版本后，都应打包并且归档。源码包的版本 由圆点隔开的两个数字组成，第一个数字表示发行 ，第二个数字表示该版的修改 。具体用法如下：

• 当源码包初版时，版本 为 V1.00；
• 当源码包被局部修改或bug修正时，发行 不变，修改 第二个数字增1。例如，对初版源码包作了第一次修订，则版本 为 V1.01；
• 当源码包在原有的基础上增加部分功能，发行 不变，修改 第一个数字增1，例如，对V1.12版的基础上增加部分功能，则新版本 为 V1.20；
• 当源码包有重要修改或局部修订累积较多导致源码包发生全局变化时，发行 增1。例如，在 V1.15 版的基础上作了一次全面修改，则新版本 为 V2.00。