?6-11 ：检查函数所有非参数输入的有效性，如数据文件、公共变量等 说明：函数的输入主要有两种：一种是参数输入；另一种是全局变量、数据文件的输入，即非参数输入。函数在使用输入之前，应进行必要的检查。

?6-12 ：函数名应准确描述函数的功能

?6-13 ：使用动宾词组为执行某操作的函数命名。如果是OOP 方法，可以只有动词（名词是对象本身） 示例：参照如下方式命名函数。

void print_record( unsigned int rec_ind ) ; int input_record( void ) ;

unsigned char get_current_color( void ) ;

建议6-14 ：避免使用无意义或含义不清的动词为函数命名

说明：避免用含义不清的动词如process、handle等为函数命名，因为这些动词并没有说明要具体做什么。

建议6-15 ：函数的返回值要清楚、明了，让使用者不容易忽视错误情况 说明：函数的每种出错返回值的意义要清晰、明了、准确，防止使用者误用、理解错误或忽视错误返回码。

?6-16 ：除非必要，最好不要把与函数返回值类型不同的变量，以编译系统默认的转换方式或强制的转换方式作为返回值返回

?6-17 ：让函数在调用点显得易懂、容易理解

?6-18 ：在调用函数填写参数时，应尽量减少没有必要的默认数据类型转换或强制数据类型转换

说明：因为数据类型转换或多或少存在危险。

?6-19 ：避免函数中不必要语句，防止程序中的垃圾代码

说明：程序中的垃圾代码不仅占用额外的空间，而且还常常影响程序的功能与性能，很可能给程序的测试、维护等造成不必要的麻烦。

?6-20 ：防止把没有关联的语句放到一个函数中

说明：防止函数或过程内出现随机内聚。随机内聚是指将没有关联或关联很弱的语句放到同一个函数或过程中。随机内聚给函数或过程的维护、测试及以后的升级等造成了不便，同时也使函数或过程的功能不明确。使用随机内聚函数，常常容易出现在一种应用场合需要改进此函数，而另一种应用场合又不允许这种改进，从而陷入困境。

在编程时，经常遇到在不同函数中使用相同的代码，许多开发人员都愿把这些代码提出来，并构成一个新函数。若这些代码关联较大并且是完成一个功能的，那么这种构造是合理的，否则这种构造将产生随机内聚的函数。 示例：如下函数就是一种随机内聚。

void Init_Var( void ) {

Rect.length = 0;

Rect.width = 0; /* 初始化矩形的长与宽 */ Point.x = 10;

Point.y = 10; /* 初始化“点”的坐标 */ }

矩形的长、宽与点的坐标基本没有任何关系，故以上函数是随机内聚。 应如下分为两个函数： void Init_Rect( void ) {

Rect.length = 0;

Rect.width = 0; /* 初始化矩形的长与宽 */ }

void Init_Point( void ) {

Point.x = 10;

Point.y = 10; /* 初始化“点”的坐标 */ }

?6-21 ：如果多段代码重复做同一件事情，那么在函数的划分上可能存在问题 说明：若此段代码各语句之间有实质性关联并且是完成同一件功能的，那么可考虑把此段代码构造成一个新的函数。

?6-22 ：功能不明确较小的函数，特别是仅有一个上级函数调用它时，应考虑把它合并到上级函数中，而不必单独存在

说明：模块中函数划分的过多，一般会使函数间的接口变得复杂。所以过小的函数，特别是扇入很低的或功能不明确的函数，不值得单独存在。

?6-23 ：设计高扇入、合理扇出（小于7 ）的函数

说明：扇出是指一个函数直接调用（控制）其它函数的数目，而扇入是指有多少上级函数调用它。

扇出过大，表明函数过分复杂，需要控制和协调过多的下级函数；而扇出过小，如总是1，表明函数的调用层次可能过多，这样不利程序阅读和函数结构的分析，并且程序运行时会对系统资源如堆栈空间等造成压力。函数较合理的扇出（调度函数除外）通常是3-5。扇出太大，一般是由于缺乏中间层次，可适当增加中间层次的函数。扇出太小，可把下级函数进一步分解多个函数，或合并到上级函数中。当然分解或合并函数时，不能改变要实现的功能，也不能违背函数间的独立性。

扇入越大，表明使用此函数的上级函数越多，这样的函数使用效率高，但不能违背函数间的独立性而单纯地追求高扇入。公共模块中的函数及底层函数应该有较高的扇入。

较良好的软件结构通常是顶层函数的扇出较高，中层函数的扇出较少，而底层函数则扇入到公共模块中。

?6-24 ：减少函数本身或函数间的递归调用

说明：递归调用特别是函数间的递归调用（如A->B->C->A），影响程序的可理解性；递归调用一般都占用较多的系统资源（如栈空间）；递归调用对程序的测试有一定影响。故除非为某些算法或功能的实现方便，应减少没必要的递归调用。

?6-25 ：仔细分析模块的功能及性能需求，并进一步细分，同时若有必要画出有关数据流图，据此来进行模块的函数划分与组织

说明：函数的划分与组织是模块的实现过程中很关键的步骤，如何划分出合理的函数结构，关系到模块的最终效率和可维护性、可测性等。根据模块的功能图或/及数据流图映射出函数结构是常用方法之一。

?6-26 ：改进模块中函数的结构，降低函数间的耦合度，并提高函数的独立性以及代码可读性、效率和可维护性 优化函数结构时，要遵守以下原则： （1）不能影响模块功能的实现。

（2）仔细考查模块或函数出错处理及模块的性能要求并进行完善。 （3）通过分解或合并函数来改进软件结构。 （4）考查函数的规模，过大的要进行分解。 （5）降低函数间接口的复杂度。

（6）不同层次的函数调用要有较合理的扇入、扇出。 （7）函数功能应可预测。

（8）提高函数内聚。（单一功能的函数内聚最高）

说明：对初步划分后的函数结构应进行改进、优化，使之更为合理。

?6-27 ：在多任务操作系统的环境下编程，要注意函数可重入性的构造 说明：可重入性是指函数可以被多个任务进程调用。在多任务操作系统中，函数是否具有可重入性是非常重要的，因为这是多个进程可以共用此函数的必要条件。另外，编译器是否提供可重入函数库，与它所服务的操作系统有关，只有操作系统是多任务时，编译器才有可能提供可重入函数库。如DOS下BC和MSC等就不具备可重入函数库，因为DOS是单用户单任务操作系统。

?6-28 ：避免使用BOOL 参数

说明：原因有二，其一是BOOL参数值无意义，TURE/FALSE的含义是非常模糊的，在调用时很难知道该参数到底传达的是什么意思；其二是BOOL参数值不利于扩充。还有NULL也是一个无意义的单词。

?6-29 ： 对于提供了返回值的函数，在引用时最好使用其返回值

?6-30 ：当一个过程（函数）中对较长变量（一般是结构的成员）有较多引用时，可以用一个意义相当的宏代替

说明：这样可以增加编程效率和程序的可读性。

示例：在某过程中较多引用TheReceiveBuffer[FirstSocket].byDataPtr， 则可以通过以下宏定义来代替：

# define pSOCKDATA TheReceiveBuffer[FirstScoket].byDataPtr

〔七〕 =====[ 可测性 ]=====

17-1 ：在同一项目组或产品组内，要有一套统一的为集成测试与系统联调准备的调测开关及相应打印函数，并且要有详细的说明 说明：本规则是针对项目组或产品组的。