华为编程规范与范例.txt

华为编程规范排版 6 2 注释 11 3 标识符命名 18 4 可读性 20 5 变量、结构 22 6 函数、过程 28

 

若改为如下，则更好些。 

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 





7 可测性 

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


17-2：在同一项目组或产品组内，调测打印出的信息串的格式要有统一的形式。信息串中至少
要有所在模块名（或源文件名）及行号。 
说明：统一的调测信息格式便于集成测试。 


17-3：编程的同时要为单元测试选择恰当的测试点，并仔细构造测试代码、测试用例，同时给
出明确的注释说明。测试代码部分应作为（模块中的）一个子模块，以方便测试代码在模块中
的安装与拆卸（通过调测开关）。 
说明：为单元测试而准备。 


17-4：在进行集成测试/系统联调之前，要构造好测试环境、测试项目及测试用例，同时仔细
分析并优化测试用例，以提高测试效率。 
说明：好的测试用例应尽可能模拟出程序所遇到的边界值、各种复杂环境及一些极端情况
等。 


17-5：使用断言来发现软件问题，提高代码可测性。 
说明：断言是对某种假设条件进行检查（可理解为若条件成立则无动作，否则应报告），
它可以快速发现并定位软件问题，同时对系统错误进行自动报警。断言可以对在系统中隐
藏很深，用其它手段极难发现的问题进行定位，从而缩短软件问题定位时间，提高系统的
可测性。实际应用时，可根据具体情况灵活地设计断言。 

示例：下面是C语言中的一个断言，用宏来设计的。（其中NULL为0L） 

#ifdef _EXAM_ASSERT_TEST_ // 若使用断言测试 

 

void exam_assert( char * file_name, unsigned int line_no ) 

{ 

 printf( "\n[EXAM]Assert failed: %s, line %u\n", 

 file_name, line_no ); 

 abort( ); 





} 

 

#define EXAM_ASSERT( condition ) 

 if (condition) // 若条件成立，则无动作 

 NULL; 

 else // 否则报告 

 exam_assert( __FILE__, __LINE__ ) 

 

#else // 若不使用断言测试 

 

#define EXAM_ASSERT(condition) NULL 

 

#endif /* end of ASSERT */ 


17-6：用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况。 
17-7：不能用断言来检查最终产品肯定会出现且必须处理的错误情况。 
说明：断言是用来处理不应该发生的错误情况的，对于可能会发生的且必须处理的情况要
写防错程序，而不是断言。如某模块收到其它模块或链路上的消息后，要对消息的合理性
进行检查，此过程为正常的错误检查，不能用断言来实现。 


17-8：对较复杂的断言加上明确的注释。 
说明：为复杂的断言加注释，可澄清断言含义并减少不必要的误用。 


17-9：用断言确认函数的参数。 
示例：假设某函数参数中有一个指针，那么使用指针前可对它检查，如下。 

int exam_fun( unsigned char *str ) 

{ 

 EXAM_ASSERT( str != NULL ); // 用断言检查“假设指针不为空”这个条件 

 

 ... //other program code 

} 


17-10：用断言保证没有定义的特性或功能不被使用。 
示例：假设某通信模块在设计时，准备提供“无连接”和“连接” 这两种业务。但当前
的版本中仅实现了“无连接”业务，且在此版本的正式发行版中，用户（上层模块）不应





产生“连接”业务的请求，那么在测试时可用断言检查用户是否使用“连接”业务。如下。 

#define EXAM_CONNECTIONLESS 0 // 无连接业务 

#define EXAM_CONNECTION 1 // 连接业务 

 

int msg_process( EXAM_MESSAGE *msg ) 

{