9.函数设计
规则 9-1 对所调用函数的错误返回码进行必要处理。
规则 9-2 函数局部变量大小，在内核态不能超过256字节，用户态不能超过2048字节。
规则 9-3 编写可重入函数时，若使用全局变量，则应通过关中断、信号量（即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;
}
规则 9-4 模块间接口函数参数的合法性检查应由接口函数本身负责，模块内部函数缺省是由函数调用者负责。
说明：对于模块间接口函数的参数的合法性检查这一问题，往往有两个极端现象，即：要么是调用者和被调用者对参数均不作合法性检查，结果就遗漏了合法性检查这一必要的处理过程，造成问题隐患；要么就是调用者和被调用者均对参数进行合法性检查，这种情况虽不会造成问题，但产生了冗余代码，降低了效率。
规则 9-5 防止将函数的参数作为工作变量。
说明：将函数的参数作为工作变量，有可能错误地改变参数内容，所以很危险。对必须改变的参数，最好先用局部变量代之，最后再将该局部变量的内容赋给该参数。
示例：下函数的实现不太好。
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;
}
规则 9-6 函数规模应该控制在200行以内，原则上是越小越好，函数内的代码应该具有较强的内聚性。
规则 9-7 不要设计多用途面面俱到的函数。
规则 9-8 函数的功能应该是可以预测的，也就是只要输入数据相同就应产生同样的输出。
说明：带有内部“存储器”的函数的功能可能是不可预测的，因为它的输出可能取决于内部存储器（如某标记）的状态。这样的函数既不易于理解又不利于测试和维护。在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;
}
规则 9-9 避免设计多参数函数，不使用的参数从接口中去掉。
说明：目的减少函数间接口的复杂度。
规则 9-10 非调度函数应减少或防止控制参数，尽量只使用数据参数。
说明：本建议目的是防止函数间的控制耦合。调度函数是指根据输入的消息类型或控制命令，来启动相应的功能实体（即函数或过程），而本身并不完成具体功能。控制参数是指改变函数功能行为的参数，即函数要根据此参数来决定具体怎样工作。非调度函数的控制参数增加了函数间的控制耦合，很可能使函数间的耦合度增大，并使函数的功能不唯一。
示例：如下函数构造不太合理。
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);
}
*规则 9-11 函数中所有的参数需要明确类型，少用void 类型。
规则 9-12 检查函数所有参数输入的有效性。
规则 9-13 检查函数所有非参数输入的有效性，如数据文件、公共变量等。
说明：函数的输入主要有两种：一种是参数输入；另一种是全局变量、数据文件的输入，即非参数输入。函数在使用输入之前，应进行必要的检查。
规则 9-14 避免函数中不必要语句，防止程序中的垃圾代码。
说明：程序中的垃圾代码不仅占用额外的空间，而且还常常影响程序的功能与性能，很可能给程序的测试、维护等造成不必要的麻烦。
规则 9-15 防止把没有关联的语句放到一个函数中。
说明：防止函数或过程内出现随机内聚。随机内聚是指将没有关联或关联很弱的语句放到同一个函数或过程中。随机内聚给函数或过程的维护、测试及以后的升级等造成了不便，同时也使函数或过程的功能不明确。使用随机内聚函数，常常容易出现在一种应用场合需要改进此函数，而另一种应用场合又不允许这种改进，从而陷入困境。
在编程时，经常遇到在不同函数中使用相同的代码，许多开发人员都愿把这些代码提出来，并构成一个新函数。若这些代码关联较大并且是完成一个功能的，那么这种构造是合理的，否则这种构造将产生随机内聚的函数。
示例：如下函数就是一种随机内聚。
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; /* 初始化“点”的坐标 */
}
规则 9-16 如果多段代码重复做同一件事情，那么在函数的划分上可能存在问题。
说明：若此段代码各语句之间有实质性关联并且是完成同一件功能的，那么可考虑把此段代码构造成一个新的函数。
规则 9-17 设计高扇入、合理扇出（小于7）的函数。
说明：扇出是指一个函数直接调用（控制）其它函数的数目，而扇入是指有多少上级函数调用它。
扇出过大，表明函数过分复杂，需要控制和协调过多的下级函数；而扇出过小，如总是1，表明函数的调用层次可能过多，这样不利程序阅读和函数结构的分析，并且程序运行时会对系统资源如堆栈空间等造成压力。函数较合理的扇出（调度函数除外）通常是3-5。扇出太大，一般是由于缺乏中间层次，可适当增加中间层次的函数。扇出太小，可把下级函数进一步分解多个函数，或合并到上级函数中。当然分解或合并函数时，不能改变要实现的功能，也不能违背函数间的独立性。
扇入越大，表明使用此函数的上级函数越多，这样的函数使用效率高，但不能违背函数间的独立性而单纯地追求高扇入。公共模块中的函数及底层函数应该有较高的扇入。
较良好的软件结构通常是顶层函数的扇出较高，中层函数的扇出较少，而底层函数则扇入到公共模块中。
规则 9-18 减少函数本身或函数间的递归调用。
说明：递归调用特别是函数间的递归调用（如A->B->C->A），影响程序的可理解性；递归调用一般都占用较多的系统资源（如栈空间）；递归调用对程序的测试有一定影响。故除非为某些算法或功能的实现方便，应减少没必要的递归调用。
规则 9-19 在多任务操作系统的环境下编程，要注意函数可重入性的构造。
说明：可重入性是指函数可以被多个任务进程调用。在多任务操作系统中，函数是否具有可重入性是非常重要的，因为这是多个进程可以共用此函数的必要条件。另外，编译器是否提供可重入函数库，与它所服务的操作系统有关，只有操作系统是多任务时，编译器才有可能提供可重入函数库。
规则 9-20 用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况，不能用断言来检查最终产品肯定会出现且必须处理的错误情况。
说明：断言是用来处理不应该发生的错误情况的，对于可能会发生的且必须处理的情况要写防错程序，而不是断言。如某模块收到其它模块或链路上的消息后，要对消息的合理性进行检查，此过程为正常的错误检查，不能用断言来实现。
规则 9-21 代码中需要添加Message信息和Debug信息。
Debug信息添加原则：
1、管理代码中所有模块外部接口函数需要在函数入口处增加DEBUG信息，内容包括输入参数信息；
2、数据通路代码DEBUG需要根据需要增加，不需增加太多，以免影响问题定位已经其他业务运行；
3、其他管理的BEBUG信息自己酌情增加修改；
Message信息添加原则：
1、 每个异常分支必须添加Message信息，并且每一条MSG信息能唯一定位代码中某一行；
2、管理通路需要再每个错误分支增加MSG打印信息，有错误码将错误码打印出来；
3、数据通路的错误分支，打印需要调用IODIR的相关接口打印。对应的打印接口为：iodir_worker_ioerr_print(worker, fmt, arg…)和iodir_plugin_ioerr_print(plugin, fmt, arg…)。
信息的格式：实体操作，都用被动句式；需要打印的item使用单中括号括起来，和value之间使用冒号分隔；内部错误，显示错误码和错误码描述，主要考虑定位问题的需要。举例如下：
1、User xxxx at IP address xxxx logged in.
2、LUN “LUN-001” is created, : xxxx, : xxxx………
3、LUN “LUN-001” is renamed, :xxxx, :xxxx…….
4、Disk xxxx is plugged in.
5、Failed to allocate memory for creating a RAID, errno[%#x], description: xxxx
10.内存管理
规则 10-1 用malloc 或new 申请内存之后，应该立即检查指针值是否为NULL。防止使用指针值为NULL的内存。
规则 10-2 不要忘记为数组和动态内存赋初值。防止将未被初始化的内存作为右值使用。
规则 10-3 防止内存操作越界。避免数组或指针的下标越界，特别要当心发生“多1”或者“少1”操作。
说明：内存操作主要是指对数组、指针、内存地址等的操作。内存操作越界是软件系统主要错误之一，后果往往非常严重，所以当我们进行这些操作时一定要仔细小心。
规则 10-4 动态内存的申请与释放必须配对，防止内存泄漏。
规则 10-5 用free 或delete 释放了内存之后，立即将指针设置为NULL，防止产生“野指针”。
11.建议
规则 11-1 代码质量保证优先原则。
（1）正确性，指程序要实现设计要求的功能。
（2）稳定性、安全性，指程序稳定、可靠、安全。
（3）可测试性，指程序要具有良好的可测试性。
（4）规范/可读性，指程序书写风格、命名规则等要符合规范。
（5）全局效率，指软件系统的整体效率。
（6）局部效率，指某个模块/子模块/函数的本身效率。
（7）个人表达方式/个人方便性，指个人编程习惯。
规则 11-2 认真处理程序所能遇到的各种出错情况。
规则 11-3 系统运行之初，要初始化有关变量及运行环境，防止未经初始化的变量被引用。
规则 11-4 严禁随意更改其它模块或系统的有关设置和配置。
规则 11-5 要时刻注意易混淆的操作符。当编完程序后，应从头至尾检查一遍这些操作符，以防止拼写错误。
说明：形式相近的操作符最容易引起误用，如C/C++中的“=”与“==”、“|”与“||”、“&”与“&&”等，若拼写错了，编译器不一定能够检查出来。
示例：如把“&”写成“&&”，或反之。
ret_flg = (pmsg->ret_flg & RETURN_MASK);
被写为：
ret_flg = (pmsg->ret_flg && RETURN_MASK);
rpt_flg = (VALID_TASK_NO( taskno ) && DATA_NOT_ZERO( stat_data ));
被写为：
rpt_flg = (VALID_TASK_NO( taskno ) & DATA_NOT_ZERO( stat_data ));
规则 11-6 精心地构造、划分子模块，并按“接口”部分及“内核”部分合理地组织子模块，以提高“内核”部分的可移植性和可重用性。
说明：对不同产品中的某个功能相同的模块，若能做到其内核部分完全或基本一致，那么无论对产品的测试、维护，还是对以后产品的升级都会有很大帮助。
规则 11-7 对于系统所提供的机制如信号量、spinlock、中断、tasklet等，对其使用约束需要有一定的了解，比如在中断处理中不能编写可能让出CPU的代码。
规则 11-8 对一些具有危险性的操作代码（如写硬盘、删数据等）要仔细考虑，防止对数据、硬件等的安全构成危害，以提高系统的安全性。
规则 11-9 资源文件（多语言版本支持），如果资源是对语言敏感的，应让该资源与源代码文件脱离，具体方法有下面几种：使用单独的资源文件、DLL文件或其它单独的描述文件（如数据库格式）。
每个公司的代码规范不同，但是自己都要注意是否能尽量做到哦！！
