C-CPP编程规范.doc

1 前言 按照软件工程方法论，程序是软件设计的自然结果，程序的质量基本取决于设计本身的质量。但是，编写程序的好坏也在很大程度上决定着程序的质量。本编程规定是建立在ANSI C语言和Structured Programming 规范的基础之上的，Structured Programming的目标是遵循“KISS”原则： Keep It Simple Stupid for： EASY TO READ、EASY TO DEBUG、EASY TO MAINTAIN。 这里强调结构化的编程规范是因为目前公司自身和公司所面向的客户都在采用过程化的编程语言C/ESQLC，因此公司的绝大多数产品需要考虑对C/ESQLC的支持，这一点在今后很长的一段时间内都要坚持贯彻。 1.1 原则 尽量使用标准的公用子程序执行既定的程序功能，禁止自行重复编写公司公用库函数中已有的处理或函数。 程序的清晰首先在于逻辑的清晰，然后才是格式的清晰。应该利用适当的阶梯形式使程序的层次结构清晰明显。 尽量采用简单的算法和数据结构，由于程序的复杂度往往直接依赖于算法和数据结构的复杂度，所以，在对程序的执行效率没有决定性影响的前提下，应尽量考虑选用简单的算法和数据结构。 不要为了时空效率而牺牲清晰性。 避免滥用语言特色----程序应简洁、易读、好懂。 应尽可能的多加注释，以帮助理解每段程序的作用。不要用注解去精确地重复代码----使注释有价值。 使用有意义的、简化的变量名及词语标号。 严格控制非限制性转移语句“GOTO”的使用，除非：当不使用时将会模糊而不是澄清功能；在同一程序单元内正向转移。 清晰随着简洁而来，不要简单认为起一个长的名字就能够增强程序的可读性，在很多时候更会起到误导和影响效率的作用。 “好的程序犹如华美的诗句“，写出“诗句”一样的程序的捷径就是模仿，因此请严格按照规范和模版的要求编写您的每一行代码。 1.2 适用范围 本规范适用于成都润信公司采用C/C++进行开发的所有软件产品和应用系统 在各产品（应用系统）的开发过程中，如果出现与本规范相抵触（或需要对本规范进行扩展时），必须先编制出该产品（应用系统）的编程规范，并报质控部经理和产品研发部经理备案，经批准后方能执行。 对于自动构造代码的某些辅助设计工具或者是集成开发环境（如ROSE和Visiual Stdio），可以不受本规范的限制，但其命名和自编代码部分必须依照本规范执行。 1.3 执行时间 本规范自2002年1月1日起正式实施，凡在2002年1月1日后开始发起的项目都必须严格遵守本规范。 1.4 罚则 凡是与本规范精神相抵触的编程规范，一律视为不合规范。检验人员有权要求作者按照规范要求重新编写，如果因重新编写导致项目延误或者其他的后果，责任由作者承担，在重新编写代码期间，原作者必须承担正常的工作分配。如果作者不服从重新编写的要求，公司有权对该作者处以行政上和经济上的处罚，情节严重者，视为严重违纪公司有权将其开除。 本规范的解释权属于成都润信科技发展有限公司产品研发部。 1.5 引用资料 《程序设计实践》 Brian W.Kernighan 和 Rob Pike 《UNIX下的编程规范》 陈学聪 1.6 建议读物 《程序设计实践》 Brian W.Kernighan 和 Rob Pike 《风格的要素》 Struck 和 White 《写可靠的代码》 Steve Maguire 2 风格 2.1 总的原则 好的程序应该具备好的风格，一般而言，好的风格具备以下特征 以缩行的形式显示程序结构 使用表达式的自然形式 采用扩号排除歧义 分解复杂的表达式 清晰、简洁 使用一致的缩行和加扩号风格 避免使用函数宏 把数定义为常数而不是宏（避免预编译器的差异和处理错误） 2.2 以缩行的形式显示程序结构 在程序中，如果本行与上一行在逻辑上有递进关系（如if、while等），则本行应比上行缩进一个TAB键位置，一般TAB键的宽度以4个空格自符为佳。花扩号应该出现在if的下一行而不是在同一行。 以下为显示不明的缩进方式： if(FEB == lMonth) { if(0 == lYear % 4) if(29 lDay) llegal = FALSE; else if(28 lDay) lLegal = FALSE; } 正确的缩进处理方式如下： if(FEB == lMonth) { if(0 == lYear % 4) { if(29 lDay) llegal = FALSE; } else { if(28 lDay) lLegal = FALSE; } } 分支是程序设计中常常面临的问题，在采用if/e