团队开发规范.docx
《团队开发规范.docx》由会员分享，可在线阅读，更多相关《团队开发规范.docx（9页珍藏版）》请在冰点文库上搜索。
团队开发规范
团队开发规范
（内部资料）
2008-8
文档信息：
文档编号
文档名称
文档描述
VSS中文档存放路径
负责人
状态
文档变更记录：
时间
修改人
章节
描述
相关文档：
文档
路径
文档确认与评审记录：
审核人
审核时间
意见
备注
目录
1编码规范的意义4
2编码规范参考5
2.1标识符命名规则5
2.2注释风格5
2.3可读性6
2.4函数命名规则6
2.5变量6
2.6排版7
2.7程序效率7
2.8质量保证7
2.9代码测试、维护8
2.10宏8
2.11可测性8
3代码优化9
3.1代码优化的意义9
3.2函数内的代码优化9
本文档对汇编程序设计的编码规范给出了建议，该建议是在C语言编码规法、C#编码规范、Delphi编码规范的基础上总结给出的，供团队小组在进行开发时使用。
编码规范的意义
程序的易读性和可维护性对于一个软件而言是非常关键的，尤其是目前编码仍然没有脱离手工劳动的阶段，保持统一的编码规范更是有着特殊的重要性。
在程序开发过程中，统一的编码规范能够：
∙增加开发过程代码的强壮性、可读性、易维护性
∙减少有经验和无经验开发人员编程所需的脑力工作
∙为软件的良好维护性打下好的基础
∙在项目范围内统一代码风格
∙通过人为以及自动的方式对最终软件应用质量标准
∙使新的开发人员快速适应项目氛围
∙支持项目资源的复用：
允许开发人员从一个项目区域（或子项目团队）移动到另一个，而不需要重新适应新的子项目团队的氛围
∙一个优秀而且职业化的开发团队所必需的素质
此外，对于汇编语言而言，由于其接近底层的特性使得其本身就具有难以理解的问题。
因此，在程序中统一编程的风格、统一变量命名、模块增加注释等措施对于维护程序的可读性、可理解性等都具有更为特殊的意义。
编码规范参考
标识符命名规则
∙标识符的命名要清晰、明了，有明确含义，同时使用完整的单词或大家基本可以理解的缩写，避免使人产生误解。
∙命名中若使用特殊约定或缩写，则要有注释说明。
∙自己特有的命名风格，要自始至终保持一致，不可来回变化。
∙对于变量命名，禁止取单个字符（如i、j、k...），建议除了要有具体含义外，还能表明其变量类型、数据类型等，但i、j、k作局部循环变量是允许的。
∙命名规范必须与所使用的系统风格保持一致，并在同一项目中统一，比如采用UNIX的全小写加下划线的风格或大小写混排的方式，不要使用大小写与下划线混排的方式。
前缀（小写字母加下划线）表明变量的作用域，无前缀则表明是局部变量或函数的参数。
注释风格
∙一般情况下，源程序有效注释量必须在20％以上。
∙说明性文件（如头文件.h文件、.inc文件、.def文件、编译说明文件.cfg等）头部应进行注释，注释必须列出：
版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等，头文件的注释中还应有函数功能简要说明。
∙源文件头部应进行注释，列出：
版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。
∙函数头部应进行注释，列出：
函数的目的/功能、输入参数、输出参数、返回值、调用关系（函数、表）等。
∙边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。
不再有用的注释要删除。
∙注释的内容要清楚、明了，含义准确，防止注释二义性。
∙避免在注释中使用缩写，特别是非常用缩写。
∙注释应与其描述的代码相近，对代码的注释应放在其上方或右方（对单条语句的注释）相邻位置，不可放在下面，如放于上方则需与其上面的代码用空行隔开。
∙对于所有有物理含义的变量、常量，如果其命名不是充分自注释的，在声明时都必须加以注释，说明其物理含义。
变量、常量、宏的注释应放在其上方相邻位置或右方。
∙数据结构声明（包括数组、结构、类、枚举等），如果其命名不是充分自注释的，必须加以注释。
对数据结构的注释应放在其上方相邻位置，不可放在下面；对结构中的每个域的注释放在此域的右方。
∙全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明。
∙注释与所描述内容进行同样的缩排。
∙将注释与其上面的代码用空行隔开。
∙对变量的定义和分支语句（条件分支、循环语句等）必须编写注释。
∙应该写优雅的、可读性良好的代码，而不是为玄妙、晦涩的代码写注释
∙原则上应尽量减少程序体内代码的注释，应该保持代码本身的直接可读性
可读性
避免使用不易理解的数字，用有意义的标识来替代。
涉及物理状态或者含有物理意义的常量，不应直接使用数字，必须用有意义的枚举或宏来代替。
函数命名规则
∙函数名用首字母大写的英文单词组合表示（如用动词+名词的方法），其中至少有一个动词
∙应该避免的命名方式
只由一个动词组成，如：
Save、Update。
改成如：
SaveValue、UpdateDataSet则比较好
∙函数参数的命名规则
函数参数应该具有自我描述性，应该能够做到见其名而知其意
用匈牙利命名法命名
∙对所调用函数的错误返回码要仔细、全面地处理。
∙明确函数功能，精确（而不是近似）地实现函数设计。
∙应注意局部变量的使用（如寄存器变量）。
变量
∙去掉没必要的公共变量。
∙仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系。
∙明确公共变量与操作此公共变量的函数或过程的关系，如访问、修改及创建等。
∙当向公共变量传递数据时，要十分小心，防止赋与不合理的值或越界等现象发生。
排版
∙程序块要采用缩进风格编写，缩进的TAB键一个。
∙相对独立的程序块之间、变量说明之后必须加空行。
∙较长的语句（>80字符）要分成多行书写，划分出的新行要进行适当的缩进，使排版整齐，语句可读。
∙若函数或过程中的参数较长，则要进行适当的划分。
∙不允许把多个短语句写在一行中，即一行只写一条语句。
∙对齐只使用TAB键，不使用空格键。
∙程序块的分界符（如C/C++语言的大括号'{'和'}'）应各独占一行并且位于同一列，同时与引用它们的语句左对齐。
∙在两个以上的关键字、变量、常量进行对等操作时，它们之间的操作符之前、之后或者前后要加空格；进行非对等操作时，如果是关系密切的立即操作符（如－>），后不应加空格。
∙程序结构清析，简单易懂，单个函数的程序行数不得超过100行。
程序效率
∙编程时要经常注意代码的效率。
∙在保证软件系统的正确性、稳定性、可读性及可测性的前提下，提高代码效率。
∙局部效率应为全局效率服务，不能因为提高局部效率而对全局效率造成影响。
∙通过对系统数据结构的划分与组织的改进，以及对程序算法的优化来提高空间效率。
∙循环体内工作量最小化。
质量保证
∙在软件设计过程中构筑软件质量。
∙代码质量保证优先原则
∙防止内存操作越界。
∙认真处理程序所能遇到的各种出错情况。
∙系统运行之初，要初始化有关变量及运行环境，防止未经初始化的变量被引用。
∙系统运行之初，要对加载到系统中的数据进行一致性检查。
∙严禁随意更改其它模块或系统的有关设置和配置。
∙不能随意改变与其它模块的接口。
∙充分了解系统的接口之后，再使用系统提供的功能。
∙编程时，要防止差1错误。
∙单元测试也是编程的一部份，提交联调测试的程序必须通过单元测试。
代码测试、维护
∙单元测试要求至少达到语句覆盖。
∙单元测试开始要跟踪每一条语句，并观察数据流及变量的变化。
∙清理、整理或优化后的代码要经过审查及测试。
∙代码版本升级要经过严格测试。
∙正式版本上软件的任何修改都应有详细的文档记录。
宏
∙用宏定义表达式时，要使用完备的括号。
∙将宏所定义的多条表达式放在大括号中。
∙使用宏时，不允许参数发生变化
可测性
∙在同一项目组或产品组内，要有一套统一的为集成测试与系统联调准备的调测开关及相应打印函数，并且要有详细的说明。
∙在同一项目组或产品组内，调测打印出的信息串的格式要有统一的形式。
信息串中至少要有所在模块名（或源文件名）及行号。
∙编程的同时要为单元测试选择恰当的测试点，并仔细构造测试代码、测试用例，同时给出明确的注释说明。
测试代码部分应作为（模块中的）一个子模块，以方便测试代码在模块中的安装与拆卸（通过调测开关）。
∙在进行集成测试/系统联调之前，要构造好测试环境、测试项目及测试用例，同时仔细分析并优化测试用例，以提高测试效率。
∙在软件系统中设置与取消有关测试手段，不能对软件实现的功能等产生影响。
∙用调测开关来切换软件的DEBUG版和正式版，而不要同时存在正式版本和DEBUG版本的不同源文件，以减少维护的难度。
∙软件的DEBUG版本和发行版本应该统一维护，不允许分家，并且要时刻注意保证两个版本在实现功能上的一致性。
∙正式软件产品中应把断言及其它调测代码去掉（即把有关的调测开关关掉）。
代码优化
代码优化的意义
∙仅仅对符合功能说明书的要求、能正确运行的代码进行优化是有意义的
∙代码优化能减少冗余代码的数量，用更少的代码来实现同样的功能
∙提高代码的内聚程度，减少耦合程度
∙对代码的抽象能提高代码的重用度，对今后其他项目的进度有非常重要的意义
函数内的代码优化
∙去掉从来没有用到过的参数
∙始终进行参数检验。
不要认为只有我才会调用这个函数，我能够保证参数的有效性。
事实上很多运行错误就是没有对参数进行检验。
对于传入了非法值的函数调用，可以返回一个对调用无意义的值（如：
null，-1），或者干脆抛出一个异常
∙函数的参数不宜过多
∙如果函数中用到的变量或者其他全局变量可以用传入参数的方式代替，则用参数代替，这样可以减少该函数和外界的关系，提高内聚
∙一个单一的函数的代码量不宜过多。
如果实在很多，则可以把它切分成小的函数
∙单个函数中尽量避免相同的代码，可以用条件语句或者抽取出来作为函数的方法消除这些冗余
∙尽量保持函数只有一个出口
升级会员 