华为软件编程规范和范例 4 —— 函数、过程

6. 函数、过程

6.1    对所调用函数的错误返回码要仔细、全面地处理。

6.2    明确函数功能, 精确(而不是近似)地实现函数设计。

6.3    编写可重入函数时, 应注意局部变量的使用(如编写C/C++ 语言的可重入函数时, 应使用auto 即缺省态 局部变量或寄存器变量)

说明: 编写C/C++语言的可重入函数时, 不应使用static局部变量, 否则必须经过特殊处理, 才能使函数具有可重 入性。


6.4    编写可重入函数时, 若使用全局变量, 则应通过关中断、信号量(即P、V 操作)等手段对其加以保护。

说明: 若对所使用的全局变量不加以保护, 则此函数就不具有可重入性, 即当多个进程调用此函数时, 很有可能使有关 全局变量变为不可知状态。

示例: 假设Exam是int型全局变量, 函数Squre_Exam返回Exam平方值。那么如下函数不具有可重入性。

unsigned int example( int para )

{

    unsigned int temp;

    Exam = para; // (**)

    temp = Square_Exam( );
    return temp;
}

此函数若被多个进程调用的话, 其结果可能是未知的, 因为当(**)语句刚执行完后, 另外一个使用本函数的进程可能正好被激活, 那么当新激活的进程执行到此函数时, 将使Exam赋与另一个不同的para值, 所以当控制重新回到“temp = Square_Exam( )”后, 计算出的temp很可能不是预想中的结果。此函数应如下改进。

unsigned int example( int para )

{

    unsigned int temp;

    [申请信号量操作]        // 若申请不到“信号量”, 说明另外的进程正处于

    Exam = para;            // 给Exam赋值并计算其平方过程中(即正在使用此

    temp = Square_Exam( );  // 信号), 本进程必须等待其释放信号后, 才可继

    [释放信号量操作]        // 续执行。若申请到信号, 则可继续执行, 但其

                            // 它进程必须等待本进程释放信号量后, 才能再使

                            // 用本信号。

    return temp;

}

6.5    在同一项目组应明确规定对接口函数参数的合法性检查应由函数的调用者负责还是由接口函数本身负责, 缺省是由函数调用者负责
说明: 对于模块间接口函数的参数的合法性检查这一问题, 往往有两个极端现象, 即: 要么是调用者和被调用者对参数均不作合法性检查, 结果就遗漏了合法性检查这一必要的处理过程, 造成问题隐患; 要么就是调用者和被调用者均对参数进行合法性检查, 这种情况虽不会造成问题, 但产生了冗余代码, 降低了效率。

½6-1 : 防止将函数的参数作为工作变量

说明: 将函数的参数作为工作变量, 有可能错误地改变参数内容, 所以很危险。对必须改变的参数, 最好先用局部变量代之, 最后再将该局部变量的内容赋给该参数。
示例: 下函数的实现不太好。

void sum_data( unsigned int num, int *data, int *sum )

{

    unsigned int count;

    *sum = 0;

    for (count = 0; count < num; count++)

    {

        *sum  += data[count]; // sum成了工作变量, 不太好。

    }

}

若改为如下, 则更好些。

void sum_data( unsigned int num, int *data, int *sum )

{

    unsigned int count ;

    int sum_temp;

    sum_temp = 0;

    for (count = 0; count < num; count ++)

    {

        sum_temp  += data[count];

    }

    *sum = sum_temp;

}

½6-2 : 函数的规模尽量限制在200 行以内

说明: 不包括注释和空格行。


½6-3 : 一个函数仅完成一件功能


½6-4 : 为简单功能编写函数

说明: 虽然为仅用一两行就可完成的功能去编函数好象没有必要, 但用函数可使功能明确化, 增加程序可读性, 亦可方便维护、测试。

示例: 如下语句的功能不很明显。

value = ( a > b ) ? a : b ;

改为如下就很清晰了。

int max (int a, int b)

{

    return ((a > b) ? a : b);

}

value = max (a, b);

或改为如下。

#define MAX (a, b) (((a) > (b)) ? (a) : (b))

value = MAX (a, b);

½6-5 : 不要设计多用途面面俱到的函数

说明: 多功能集于一身的函数, 很可能使函数的理解、测试、维护等变得困难。


½6-6 : 函数的功能应该是可以预测的, 也就是只要输入数据相同就应产生同样的输出

说明: 带有内部“存储器”的函数的功能可能是不可预测的, 因为它的输出可能取决于内部存储器(如某标记)的状态。这样的函数既不易于理解又不利于测试和维护。在C/C++语言中, 函数的static局部变量是函数的内部存储器, 有可能使函数的功能不可预测, 然而, 当某函数的返回值为指针类型时, 则必须是STATIC的局部变量的地址作为返回值, 若为AUTO类, 则返回为错针。

示例: 如下函数, 其返回值(即功能)是不可预测的。

unsigned int integer_sum( unsigned int base )

{

    unsigned int index;

    static unsigned int sum = 0; // 注意, 是static类型的。

                                 // 若改为auto类型, 则函数即变为可预测。

    for (index = 1; index <= base; index++)

    {

        sum += index;

    }

    return sum;

}

½6-7 : 尽量不要编写依赖于其他函数内部实现的函数

说明: 此条为函数独立性的基本要求。由于目前大部分高级语言都是结构化的, 所以通过具体语言的语法要求与编译器功能, 基本就可以防止这种情况发生。但在汇编语言中, 由于其灵活性, 很可能使函数出现这种情况。
示例: 如下是在DOS下TASM的汇编程序例子。过程Print_Msg的实现依赖于Input_Msg的具体实现, 这种程序是非结构化的, 难以维护、修改。

...  // 程序代码

proc Print_Msg // 过程(函数)Print_Msg

    ...  // 程序代码

    jmp  LABEL

    ...  // 程序代码

endp

proc Input_Msg // 过程(函数)Input_Msg

    ...  // 程序代码

LABEL:

    ...  // 程序代码

endp

½6-8 : 避免设计多参数函数, 不使用的参数从接口中去掉

说明: 目的减少函数间接口的复杂度。


½6-9 : 非调度函数应减少或防止控制参数, 尽量只使用数据参数

说明: 本建议目的是防止函数间的控制耦合。调度函数是指根据输入的消息类型或控制命令, 来启动相应的功能实体(即函数或过程), 而本身并不完成具体功能。控制参数是指改变函数功能行为的参数, 即函数要根据此参数来决定具体怎样工作。非调度函数的控制参数增加了函数间的控制耦合, 很可能使函数间的耦合度增大, 并使函数的功能不唯一。

示例: 如下函数构造不太合理。

int add_sub( int a, int b, unsigned char add_sub_flg )

{

    if (add_sub_flg == INTEGER_ADD)

    {

        return (a + b);

    }

    else

    {

        return (a  b);

    }

}

不如分为如下两个函数清晰。

int add( int a, int b )

{

    return (a + b);

}

int sub( int a, int b )

{

    return (a  b);

}

½6-10 : 检查函数所有参数输入的有效性


½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