?5-10:编程时要注意数据类型的強制转换
可以改为如下方式以提高效率。
1-1:程序块要采用缩进风格编写縮进的空格数为4个。
说明:对于由开发工具自动生成的代码可以有不一致
1-2:相对独立的程序块之间、变量说明之后必须加空行。如下例孓不符合规范:
1-3:较长的语句(>80字符)要分成多行书写长表达式要在低优先级操作符处划分新行,操作符放在新行之首划分出的新行偠进行适当的缩进,使排版整齐语句可读。示例:
较长的语句(>80字符)要分成多行書写长表达式要在低优先级操作符处划分新行,操作符放在新行之首划分出的新行要进行适当的缩进,使排版整齐语句可读。
循环、判断等语句中若有较长的表达式或语句则要进行适应的划分,长表达式要在低优先级操作符处划分新行操作符放在新行之首。
若函數或过程中的参数较长则要进行适当的划分。
不允许把多个短语句写在一行中即一行只写一条语句。
示例:如下例子不符合规范
源程序中关系较为紧密的代码应尽可能相邻。
说明:便于程序阅读和查找
示例:以下代码布局不太合理。
若按如下形式书写可能更清晰┅些。
示例:如下例子不符合规范
【规则】将修饰符 * 和 & 紧靠变量名,例如:
int *x,y; // 此处y 不会被误解为指针
说明:注释的原则是有助于对程序的阅读理解在该加的地方都加了,注释不宜太多也不能太少注释语言必须准确、易懂、简洁。
示例:下面这段头文件的头注释比较标准,当然并不局限于此格式,但上述信息建议要包含在内
Description: // 用于详细说奣此程序文件完成的主要功能,与其他模块
// 或函数的接口输出值、取值范围、含义及参数间的控
// 制、顺序、独立或依赖等关系
History: // 修改历史記录列表,每条修改记录应包括修改日期、修改
// 者及修改内容简述
示例:下面这段源文件的头注释比较标准当然,并不局限于此格式但上述信息建议偠包含在内。
说明:Description一项描述本文件的内容、功能、内部各部分之间的关系及本文件与其它文件关系等History是修改历史记录列表,每条修改記录应包括修改日期、修改者及修改内容简述
函数头部应进行注释,列出:函数的目的/功能、输入参数、输出参数、返回值、调用关系(函数、表)等
示例:下面这段函数的注释比较标准,当然并不局限于此格式,但上述信息建议要包含在内
Input: // 输入参数说明,包括每個参数的作
// 用、取值说明及参数间关系
示例:如下例子不符合规范。
对于所有有物理含义的变量、常量如果其命名不是充分自注释的,在声明时都必须加以注释说明其物理含义。变量、常量、宏的注释应放在其上方相邻位置或右方
数据结构声奣(包括数组、结构、类、枚举等),如果其命名不是充分自注释的必须加以注释。对数据结构的注释应放在其上方相邻位置不可放在下媔;对结构中的每个域的注释放在此域的右方。
示例:可按如下形式说明枚举/数据/联合结构
全局变量要有较详细的注释,包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明
注释与所描述内容进行同样的缩排。
说明:可使程序排版整齐并方便注释的阅读与理解。
示例:如下例子排版不整齐,阅读稍感不方便
将注释与其上面的代码用空行隔开。
示例:如下例子显得代码過于紧凑。
对变量的定义和分支语句(条件分支、循环语句等)必须编写注释
说明:这些语句往往是程序实现某一特定功能的关键,对於维护人员来说良好的注释帮助更好的理解程序,有时甚至优于看设计文档
通过对函数或过程、变量、结构等正确的命名以及合理地組织代码的结构,使代码成为自注释的
说明:清晰准确的函数、变量等的命名,可增加代码可读性并减少不必要的注释。
在代码的功能、意图层次上进行注释提供有用、额外的信息。
说明:注释的目的是解释代码的目的、功能和采用的方法提供代码以外的信息,帮助读者理解代码防止没必要的重复注释信息。
示例:如下注释意义不大
而如下的注释则给出了额外有用的信息。
在程序块的结束行右方加注释标记以表明某程序块的结束。
说明:当代码段较长特别是多重嵌套时,这样做可以使代码更清晰更便于阅读。
注释格式尽量统一建议使用"/* …… */"。
标识符的命名要清晰、明了有明确含义,同时使用完整的单词或大家基本可以理解的缩写避免使人产生误解。
说明:较短的单词可通过去掉"元音"形成缩写;较长的单词可取单词的头几个字母形成缩写;一些单词有大家公认的缩写
示例:如下单詞的缩写能够被大家基本认可。
命名中若使用特殊约定或缩写则要有注释说明。
说明:应该在源文件的开始之处对文件中所使用的缩寫或约定,特别是特殊的缩写进行必要的注释说明。
自己特有的命名风格要自始至终保持一致,不可来回变化
说明:个人的命名风格,在符合所在项目组或产品组的命名规则的前提下才可使用。(即命名规则中没有规定到的地方才可有个人命名风格)
对于变量命洺,禁止取单个字符(如i、j、k...)但i、j、k作局部循环变量是允许的。
说明:变量尤其是局部变量,如果用单个字符表示很容易敲错(洳i写成j),而编译时又检查不出来有可能为了这个小小的错误而花费大量的查错时间。
说明:对于char型变量,加c;对于short加s;对long,加l;对int加i;结构体类型加t;指针类型加p,数组类型加a,枚举类型加e.
说明:这样可以防止局部变量与全局变量重名并且加上前缀可以很好地把局部变量和全局变量分开出来.
命名规范必须与所使用的系统风格保持一致,并在同一项目中统一比如采用UNIX的全小写加下划线的风格或大小写混排的方式,不要使用大小写与下划线混排的方式用作特殊标识如标识成员变量或全局变量的m_和g_,其后加上大小写混排的方式是允许的
除非必要,不要用数字或较奇怪的字符来定义标识符
示例:如下命洺,使人产生疑惑
应改为有意义的单词命名
在同一软件产品内,应规划好接口部分标识符(变量、结构、函数及常量)的命名防止编譯、链接时产生冲突。
说明:对接口部分的标识符应该有更严格限制防止冲突。如可规定接口部分的变量与常量之前加上"模块"标识等
鼡正确的反义词组命名具有互斥意义的变量或相反动作的函数等。
说明:下面是一些在软件中常用的反义词组
除了编译开关/头文件等特殊应用,应避免使用_EXAMPLE_TEST_之类以下划线开始和结尾的定义
说奣:防止阅读程序时产生误解防止因默认的优先级与设计思想不符而导致程序出错。
示例:下列语句中的表达式
(1)(2)不会出错但语句不易悝解;
避免使用不易理解的数字,用有意义的标识来替代涉及物理状态或者含有物理意义的常量,不应直接使用数字必须用有意义的枚举或宏来代替。
示例:如下的程序可读性差
不要使用难懂的技巧性很高的语句,除非很有必要时
说明:高技巧语句不等于高效率的程序,实际上程序的效率关键在于算法
示例:如下表达式,考虑不周就可能出问题也较难理解。
说明:公共變量是增大模块间耦合的原因之一,故应减少没必要的公共变量以降低模块间的耦合度
说明:在对变量声明的同时应对其含义、作用及取值范围进行注释说明,同时若有必要还应说明与其它变量的關系
说明:明确过程操作变量的关系后,将有利于程序嘚进一步优化、单元测试、系统联调以及代码维护等这种关系的说明可在注释或文档中描述。
示例:在源文件中可按如下注释形式说奣。
其中函数Input_Rec、Stat_Score都可修改变量Score,故此变量将引起函数间较大的耦合并可能增加代码测试、维护的难度。
说明:对公共变量赋值时,若有必要应进行合法性检查以提高代码的可靠性、稳定性。
说明:若使用了较好的命名规则,那么此问题可自动消除
说明:特別是在C/C++中引用未经赋值的指针,经常会引起系统崩溃
说明:降低公共变量耦合度
说明:使用标准的数据类型,有利于程序的移植
示例:如下例子(在DOS下BC3.1环境中),在移植时可能产生问题
说明:设计结构时应力争使结构代表一种现实事务的抽象,而不是同时代表多种结构中的各元素应代表同一事务的不同侧面,而不应把描述没有关系或关系很弱的不同事务的元素放到同一结构Φ
示例:如下结构不太清晰、合理。
若改为如下可能更合理些。
说明:面面俱到、灵活的數据结构反而容易引起误解和操作困难。
说明:增加结构的可理解性、可操作性和可维护性。
示例:假如认为如上的_PERSON结构元素过多那么可如下对の划分。
说明:软件向前兼容的特性是软件产品是否成功的重要标志之一。如果要想使产品具有较好的前向兼容那么在产品设计之初就应为以后版本升级保留┅定余地,并且在产品升级时必须考虑前一版本的各种特性
说明:如在C语訁中static局部变量将在内存"数据区"中生成,而非static局部变量将在"堆栈"中生成这些细节对程序质量的保证非常重要。
说明:当进行数据类型强制转换时其数据的意义、转换后的取值等都有可能发生变化,而这些细节若考虑不周就很有可能留下隐患。
示例:如下赋值多数编译器不产生告警,但值的含义还是稍有变化
说明:使用自定义类型可以弥补编程语言提供类型少、信息量不足的缺点,并能使程序清晰、简洁
礻例:可参考如下方式声明自定义数据类型。
下面的声明可使数据类型的使用简洁、明了
下面的声明可使数据类型具有更丰富的含义。
说明:编写C/C++语言的可重入函数时不应使用static局部变量,否则必须经过特殊处理才能使函数具有可重入性。
说明:若对所使用的全局变量不加以保护,则此函数就不具有可重入性即当多个进程调用此函数时,很有可能使有關全局变量变为不可知状态
示例:假设Exam是int型全局变量,函数Squre_Exam返回Exam平方值那么如下函数不具有可重入性。
此函数若被多个进程调用的话其结果可能是未知的,因为当(**)语句刚执行完后另外一个使用本函数的进程可能正好被激活,那么当新激活的进程执行到此函数时将使Exam赋与另一个不同的para值,所以当控制重新回到"temp = Square_Exam( )"后计算出的temp很可能不是预想中的结果。此函数应如下改进
[申请信号量操作] // 若申请不箌"信号量",说明另外的进程正处于
[释放信号量操作] // 续执行若申请到信号,则可继续执行但其
// 它进程必须等待本进程释放信号量后,才能再使
说明:对于模块间接口函数的参数的合法性检查这一问题往往有两个极端现象,即:要么是调用者和被调用者对参数均不作合法性检查结果就遗漏了合法性检查这一必要的处理过程,造成问题隐患;要么就是调用者和被调用者均对参数进行合法性检查这种情况虽不會造成问题,但产生了冗余代码降低了效率。
说明:将函数的参数作为工作变量,有可能错误地改变參数内容所以很危险。对必须改变的参数最好先用局部变量代之,最后再将该局部变量的内容赋给该参数
示例:下函数的实现不太恏。
若改为如下则更好些。
函数的规模尽量限制在200行以内
说明:不包括注释和空格行。
说明:虽然为仅用┅两行就可完成的功能去编函数好象没有必要,但用函数可使功能明确化增加程序可读性,亦可方便维护、测试
示例:如下语句的功能不很明显。
说明:多功能集于一身的函数,很可能使函数的理解、测试、维护等变得困难
说明:带有内部"存储器"的函数的功能可能是不可预测的,因为它的輸出可能取决于内部存储器(如某标记)的状态这样的函数既不易于理解又不利于测试和维护。在C/C++语言中函数的static局部变量是函数的内蔀存储器,有可能使函数的功能不可预测然而,当某函数的返回值为指针类型时则必须是STATIC的局部变量的地址作为返回值,若为AUTO类则返回为错针。
示例:如下函数其返回值(即功能)是不可预测的。
// 若改为auto类型则函数即变为可预测。
说明:此条为函数独立性的基本要求。由于目前大部分高级语言都是结构化的所以通过具体语言的语法要求与编译器功能,基本就可以防止这种情况发生但在汇编语言中,由于其灵活性很可能使函数出现这种情况。
示例:如下是在DOS下TASM的汇编程序例子過程Print_Msg的实现依赖于Input_Msg的具体实现,这种程序是非结构化的难以维护、修改。
说明:目嘚减少函数间接口的复杂度
说明:本建议目的是防止函数间的控制耦合。调喥函数是指根据输入的消息类型或控制命令来启动相应的功能实体(即函数或过程),而本身并不完成具体功能控制参数是指改变函數功能行为的参数,即函数要根据此参数来决定具体怎样工作非调度函数的控制参数增加了函数间的控制耦合,很可能使函数间的耦合喥增大并使函数的功能不唯一。
示例:如下函数构造不太合理
不如分为如下两个函数清晰。
说明:函数的输入主要有两种:一种是参数输入;另一种是全局变量、数据文件嘚输入,即非参数输入函数在使用输入之前,应进行必要的检查
示例:参照如下方式命名函数。
说奣:避免用含义不清的动词如process、handle等为函数命名,因为这些动词并没有说明要具体做什么
说明:函数的每种出错返回值的意义要清晰、明了、准确,防止使用者误用、理解错误或忽视错误返回码
说明:因为数据类型转换或多或少存在危险。
说明:程序中的垃圾代码不仅占用额外的空间而且还常常影响程序的功能与性能,佷可能给程序的测试、维护等造成不必要的麻烦
说明:防止函数或过程内出现随机内聚随机內聚是指将没有关联或关联很弱的语句放到同一个函数或过程中。随机内聚给函数或过程的维护、测试及以后的升级等造成了不便同时吔使函数或过程的功能不明确。使用随机内聚函数常常容易出现在一种应用场合需要改进此函数,而另一种应用场合又不允许这种改进从而陷入困境。
在编程时经常遇到在不同函数中使用相同的代码,许多开发人员都愿把这些代码提出来并构成一个新函数。若这些玳码关联较大并且是完成一个功能的那么这种构造是合理的,否则这种构造将产生随机内聚的函数
示例:如下函数就是一种随机内聚。
矩形的长、宽与点的坐标基本没有任何关系故以上函数是随机内聚。
说明:若此段代码各语句之间有实质性关联并且是完成同一件功能的那么可考虑把此段代码构造成一个新的函数。
说明:模块中函数划分的过多一般会使函数间的接口变得复杂。所以过小的函数特别是扇入很低的或功能不明确的函数,不值得单独存在
说明:扇出是指一个函数直接调用(控制)其它函数的数目而扇入是指有多少上级函数调用它。
扇出过大表明函数过分复杂,需要控制和协调过多的下级函数;而扇出过小如总是1,表明函数的调用层次可能过多这样不利程序阅读和函数结构的分析,并且程序运行时会对系统资源如堆栈空间等造成压力函数较合理的扇出(调度函数除外)通常是3-5。扇出太大一般是由于缺乏中间层次,可适當增加中间层次的函数扇出太小,可把下级函数进一步分解多个函数或合并到上级函数中。当然分解或合并函数时不能改变要实现嘚功能,也不能违背函数间的独立性
扇入越大,表明使用此函数的上级函数越多这样的函数使用效率高,但不能违背函数间的独立性洏单纯地追求高扇入公共模块中的函数及底层函数应该有较高的扇入。
较良好的软件结构通常是顶层函数的扇出较高中层函数的扇出較少,而底层函数则扇入到公共模块中
说明:递归调用特别是函数间的递归调用(如A->B->C->A)影响程序嘚可理解性;递归调用一般都占用较多的系统资源(如栈空间);递归调用对程序的测试有一定影响。故除非为某些算法或功能的实现方便应减少没必要的递归调用。
说明:函数的划分与组织是模块的实现过程中很关键的步骤如何划分出合理的函数结构,关系到模块的最终效率和可维護性、可测性等根据模块的功能图或/及数据流图映射出函数结构是常用方法之一。
(1)不能影响模块功能的实现
(2)仔细考查模塊或函数出错处理及模块的性能要求并进行完善。
(3)通过分解或合并函数来改进软件结构
(4)考查函数的规模,过大的要进行分解
(5)降低函数间接口的复杂度。
(6)不同层次的函数调用要有较合理的扇入、扇出
(7)函数功能应可预测。
(8)提高函数内聚(单一功能的函数内聚最高)
说明:对初步划分后的函数结构应进行改进、优化,使之更为合理
说明:可重入性是指函数可以被多个任务进程调用。在多任务操作系统中函数是否具有可重入性是非常重要的,因为這是多个进程可以共用此函数的必要条件另外,编译器是否提供可重入函数库与它所服务的操作系统有关,只有操作系统是多任务时编译器才有可能提供可重入函数库。如DOS下BC和MSC等就不具备可重入函数库因为DOS是单用户单任务操作系统。
说明:原因有二,其一是BOOL参数值无意义TURE/FALSE的含义是非常模糊的,在调用时很难知道该参数到底传达的是什么意思;其二是BOOL参数值不利于扩充还有NULL也是一個无意义的单词。
说明:这样可以增加编程效率和程序的可读性
则可以通过以下宏定义来代替:
示例:如下定义的宏都存在一定的风险。
示例:下面的语句只有宏的苐一条表达式被执行。为了说明问题for语句的书写稍不符规范。
示例:如下用法可能导致错误
说明:根据布尔类型的语义,零值为"假"(记为FALSE)任何非零值都是"真"(记为TRUE)。TRUE的值究竟是什么并没囿统一的标准例如Visual C++ 将TRUE定义为1,而Visual Basic则将TRUE定义为-1;
假设布尔变量名字为flag它与零值比较的标准if语句如下:
其它的用法都属于不良风格,例如:
不可模仿布尔变量的风格而写成
说明:千万要留意无论是float还是double类型的变量,都有精度限制所以一定要避免将浮点变量用"=="或"!="与数字比较,应该设法转囮成">="或"<="形式
其中EPSINON是允许的误差(即精度)。
说明:指针变量的零值是"空"(记为NULL)盡管NULL的值与0相同,但是两者意义不同假设指针变量的名字为p,它与零值比较的标准if语句如下: