软件编码规范编制审核批准发布日期 20XX-XX-XX目录1 计划规范 (6)1.1考虑冗余时间 (6)1.2尽早制定软件部署方案和用户反馈方案 (6) (6)2 版本规范 (8)3 C/C++代码规范 (9)3.1排版、布局 (9)3.2注释 (11)3.3命名 (13)3.4可读性 (14)3.5变量、结构 (14)3.6函数、过程 (15)3.7类 (16)3.8可测性 (16)3.9程序效率 (17)3.10质量保证 (17)3.11代码编辑、编译、审查 (18)3.12代码测试 (19)3.13宏 (19)3.14其他 (21)阅读说明：◆加“【强制】”的条款为必须满足的内容。
◆加“【建议】”的条款为建议性的内容，根据具体情况实行，不做检查。
◆加“【说明】”的为补充性内容，可以作为实行与检查的依据。
◆其他条款默认为检查项，如果在某些情况下违反，说明理由。
1计划规范1.1 考虑冗余时间软件设计的工时预估是世界公认“估不准”问题，这是导致软件行业“加班”与“跳票”的重要原因。
现在比较通行的做法是：◆【建议】软件设计工作划分得尽量细；◆【建议】由具体的设计人员和上一级管理者预估具体任务的完成时间；◆【建议】在所有统计工时的基础上增加80%的时间；◆【建议】根据工作的进展尽早汇报并调整计划；1.2 尽早制定软件部署方案和用户反馈方案◆【建议】有些部署与反馈方案要在软件内部实现，比如：在线升级、故障数据保存与发送。
这些是软件设计的一部分，应整体考虑。
2版本规范◆【建议】软件产品(可执行文件、动态库等)和安装包使用如X.Y.Z.T的四段版本。
X.Y为主版本号，Z:功能变化时+1；T:逐次编译+1；功能变化且重新编译时，Z+1，T重新置0。
3C/C++代码规范3.1 排版、布局【目标】清晰，利于阅读，防范低级错误。
◆缩进为4个字符宽（使用TAB键，其宽度设置为4个空格）。
◆【建议】函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格，case语句下的情况处理语句也要遵从语句缩进要求。
◆【建议】程序块的分界符（如‘{’和‘}’）应各独占一行并且位于同一列，同时与引用它们的语句左对齐。
在函数体的开始、类的定义、结构的定义、枚举的定义以及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。
◆【建议】预处理指令不需要缩进，总是从行首开始。
即使预处理指令位于缩进代码块中，指令也应从行首开始。
◆相对独立的程序逻辑块之间加空行。
◆【建议】函数内部逻辑块之间加入一个空行，每个类声明后加入空行，函数之间加两个空行。
◆【建议】代码行长度超过80个字符时分行。
◆【建议】较长的语句要分成多行书写，划分出的新行要进行适当的缩进，使排版整齐，语句可读。
◆【建议】长表达式要在低优先级操作符处划分新行，操作符放在新行之首。
◆若函数由于参数过程多而使语句过长，则每个参数（包括类型）单独一行参数行对齐。
◆【建议】循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分。
◆【建议】若函数或过程中的参数较长，则要进行适当的划分。
◆不允许把多个短语句写在一行中，即一行只写一条语句（宏定义与闭包中的除外）。
◆if、for、do、while、case、switch、default等语句自占一行，且if、for、do、while等语句的执行语句部分无论多少都要加括号{}。
◆程序块的分界符（如C/C++语言的大括号‘{’和‘}’）应各独占一行并且位于同一列，同时与引用它们的语句左对齐。
◆【建议】适当加入空格使语句语义清晰。
由于留空格所产生的清晰性是相对的，所以，在已经非常清晰的语句中没有必要再留空格，如果语句已足够清晰则括号内侧(即左括号后面和右括号前面)不需要加空格，多重括号间不必加空格，因为在C/C++语言中括号已经是最清晰的标志了。
◆【建议】在两个以上的关键字、变量、常量进行对等操作时，它们之间的操作符之前、之后或者前后要加空格。
比如：a = b + c;◆【建议】象const、virtual、inline、case 等关键字之后至少要留一个空格，否则无法辨析关键字。
象if、for、while等关键字之后应留一个空格再跟左括号‘（’，以突出关键字。
◆【建议】函数名之后不要留空格，紧跟左括号‘（’，以与关键字区别。
◆【建议】‘（’向后紧跟，‘）’、‘，’、‘;’向前紧跟，紧跟处不留空格。
◆【建议】‘，’之后要留空格，如Function(x, y, z)。
如果‘;’不是一行的结束符号，其后要留空格。
⏹【建议】赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符，如“=”、“+=”“>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<”,“^”等二元操作符的前后应当加空格；一元操作符如“!”、“~”、“++”、“--”、“&”（地址运算符）等前后不加空格；象“［］”、“.”、“->”这类操作符前后不加空格。
◆【建议】在较长语句中，体现层次性更重要。
按操作符的优先级，适量加入空格，不必处处都加。
比如：a = x>0 ? b : c;要比：a = x > 0 ? b : c;清晰。
再比如：if (int i=0; i<MAX_CI; i++)要比：if (int i = 0; i < MAX_CI; i++)清晰。
◆【建议】遵从统一的顺序书写类的定义及实现。
类的定义（在定义文件中）按如下顺序书写：公有函数公有属性保护函数保护属性私有函数私有属性类的实现（在实现文件中）按如下顺序书写：构造函数析构函数公有函数保护函数私有函数3.2注释【目标】增加足够的信息量，利于理解。
◆在源码相关文件、编译配置文件（如MAKE文件，config文件）和其它脚本文件（如安装脚本充分文件）的头部应进行注释。
◆【建议】文件头注释包含版权声明与应用问题的说明。
示例：/********************************************************************** 版权所有(c)2008，重庆微海软件开发有限公司。
* Copyright (c) MicroSea Software Development Co. Ltd, All rights reserved.**问题：同步方式在某些情况下会造成消息丢失，原因未明，建议使用异步方式*注意：MetaDataProc2未经充分测试**********************************************************************/◆【说明】版权说明要包括中文和英文。
◆【说明】注释通常用中文写，但可以适度用简单英文，如下例中“param1”。
◆【强制】说明每个全局或公有函数的功用、参数及返回值。
示例：//purpose:用指定的宽和高生成8位DibSection对象//param0:宽//param1:高//param2:[out]，实际输出的是DibSection*指针//return:错误码，定义见define2.hint CreateDibSetion8(UINT width, UINT height, void**ppDibSetion);◆【强制】说明每个全局或公有属性、变量和常量的意义。
◆【强制】对于每个自定义类型(包括数组、结构、类、枚举等)，如果其命名不是充分自注释的，必须加以注释说明用途。
◆【说明】类型、方法、变量、宏定义等，作用域越大的，注释说明应该越多。
对私有的函数和属性按需要加注释。
◆【建议】在函数内部对逻辑分支加注释，说明什么情况下到这一分支。
◆【建议】对循环体进行注释，说明用途、循环的结束/跳出条件。
◆【建议】对特定的算法加详细说明。
◆【建议】边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。
不再有用的注释要删除。
◆【说明】注释的内容要清楚、明了，含义准确，防止注释二义性。
错误的注释不但无益反而有害。
◆【建议】注释中出现不常见的名词或缩写时进行名词解释，或给出参考资料的位置。
◆注释应与其描述的代码相近，对代码的注释应放在其上方或右方（对短语句或变量）相邻位置，不可放在下面，如放于上方则需与其上面的代码用空行隔开。
注释与所描述内容进行同样的缩排。
◆【建议】对于所有有物理含义的变量、常量，注释说明其单位。
◆【建议】通过对函数或过程、变量、结构等正确的命名以及合理地组织代码的结构，使代码成为自注释的。
◆【建议】对于未引用的函数参数，使用C风格注释将参数名注释掉。
◆【建议】在程序块的结束行右方加注释标记（‘｝’的右方），以表明某程序块的结束。
◆【建议】允许个性化，但同一模块注释风格尽量统一。
3.3命名【目标】含义贴切，用途清晰明了。
“吟安一个字，捻断数茎须”，代码中的命名虽不这样追求极致，但“命名”确是世所公认的程序员第一难题。
项目及文件的命名需要在一开始就考虑的十分合理。
对于文件内部的各种命名，在设计过程中，如果发现有更贴切表意、更合理的，替换之。
◆【建议】除了约定俗成的少数缩写或简写（如msg(message)、inc(increment)），命名尽量用完整的单词。
◆【建议】命名中若使用特殊约定或缩写，则要有注释说明。
◆【说明】对包括文件名、类名、结构体名、变量名、常量名等在内的命名，既可以使用驼峰式命名方式（如TheExample），也可以用UNIX式（如the_example）。
UNIX 式更易读，但是在Windows下编程，要考虑风格兼容问题。
◆【建议】文件名尽量使用UNIX式。
因为SVN源码管理系统对大小写是敏感的。
◆【建议】IDE生成的代码文件，后续的添加保持其风格。
与框架（如MFC）直接打交道的代码，使用框架的风格。
◆【强制】除了引用的内容（比如使用其他的库）代码风格至少在文件内部保持统一。
◆【建议】代码风格在模块级或命名空间及保持统一。
◆【建议】类名、结构体名、函数名使用首字母大写的驼峰式。
◆【建议】变量、常量使用驼峰式命名方式，首字母小写。
类成员变量前加m_，全局变量前加g_，常量前加k。
◆【建议】摈弃匈牙利命名法中类型的缩写前缀，只保留‘sz’、‘p’和‘pp’。
◆【建议】对于变量命名，除非在循环体内用作计数，禁止取单个字符。
◆【建议】程序中不要出现仅靠大小写区分的相似的标识符。
◆【建议】用正确的反义词组命名具有互斥意义的变量或相反动作的函数等。
add / remove begin / end create / destroyinsert / delete first / last get / releaseincrement / decrement put / getadd / delete lock / unlock open / closemin / max old / new start / stopnext / previous source / target show / hidesend / receive source / destinationcut / paste up / down◆【强制】宏名称中不使用小写字母。