宇眼科技C语言软件编程规范v1.0

C语言软件编程规范
拟定：黄宗灯日期：2019-01-25评审：日期：
批准：日期：
Revision Record修订记录
Date 日期Revision
Version
修订
版本
Sec
No.
修改
章节
Change Description
修改描述
Author
作者
2019-01-25v1.0All initial初稿完成黄宗灯
关键词：编程规范、软件开发规范、规则、建议、规范
摘要：本文描述了宇眼科技C语言在设计和编码过程中，需要遵循的一些基本规范。

缩略语清单：
Abbreviations缩略语Full spelling英文全名Chinese explanation中文解释
ppf Police Platform警用平台
cpf Car Platform汽车平台
fpf Fire Control Platform消防平台
ueyes UEYES宇眼科技
1.概述
1.1.目的
制定本规范的目的是在宇眼科技的开发和维护过程中，统一设计规范和编程规范，便于提高开发效率，统一风格，提高软件质量和可维护性。

1.2.本规范所规定的内容
1）目录组织结构，文件命名，头文件组织；
2）在函数设计、实现过程中所遵循的一些规范；
3）在调试，维护，源程序管理等其他方面的一些规范；
4）组件设计、裁减及配置方面的规范；
采用以下的术语描述：
规则：工作过程中强制必须遵守的原则
建议：工作过程中必须加以考虑的原则
说明：对此规则或建议进行必要的解释
2.目录结构规范
由于Unix、Linux下对字母大小写敏感，为减少出错的机率，统一规定宇眼科技所有目录名都使用小写。

3.文件组织
3.1.文件类型及命名
规则3-1-1：宇眼科技的源程序文件有如下类型的文件：
头文件：*.h
程序文件：*.c
规则3-1-2：文件名必须为小写字母；
说明：由于Unix、Linux下对文件名大小写敏感，为减少因此出错的概率，统一规定使用小写字母。

规则3-1-3：文件名前加一个表示模块的前缀以避免重名；
示例：
ply_ui.c
具体前缀请参考：4.1标识定义；
规则3-1-4：几种特殊类型的文件命名如下：
xxx_interface.h：模块的对外（提供给其他模块使用的接口）的头文件，使用该模块时需要包含的头文件；
例如：ply_interface.h
3.2.文件内容组织
规则3-2-1：公用头文件包含需要全局引用的宏定义、变量说明、结构说明和外部函数声明等。

但不应包含变量定义；
规则3-2-3：头文件包含使用相对路径，包含中的文件分隔符必须使用正斜杠（/），不能使用反斜杠（\），因为反斜杠与Linux、Unix系统下不兼容；
例如：#include"devinc/dev_state.h"
说明：头文件的具体位置可以通过设置搜索路径的方式处理，如果头文件存放位置发生改变会比较方便。

规则3-2-4：在C源程序文件中不允许声明不在本文件中定义的外部函数并直接引用；
说明：本规则是为了避免误用其他模块的内部函数。

在.c文件中声明不在本文件中定义的外部函数之后可以直接访问这个函数，但是由于被调用的函数并没有意识到这个函数被其他人使用，所以可能会独自修改其原型，最后导致错误。

如果需要使用其他模块的外部函数，应由提供该函数的模块将其明确的在.h文件中声明为外部函数，使用者必须包含该头文件。

规则3-2-5：在C源程序文件中不允许跨模块直接访问其他模块的变量，而应该有其他模块提供相应的接口进行访问。

3.3.注释
对注释的要求请参考总则的第2章。

本节未覆盖内容以总则为准，以下部分内容如与总则冲突，以本规范为准。

建议3-3-1：头文件中的每项声明都应加注释。

说明：头文件中的声明如数据结构、全局变量、函数都是代码中较重要的部分，清楚的注释有利于代码的可读性。

规则3-3-2：注释格式统一，使用“/*……*/”。

说明：一些编译器不支持C++风格的注释“//”
规则3-3-3：在#endif后面应该加上注释/**/，注释的内容为和它匹配的#if语句的内容。

示例：
#ifdef__UEYES_DEBUG__
......
#else
#error some error logs
#endif/*__UEYES_DEBUG__*/
说明：对比较复杂的编译宏（超过6行或以上），应该采用上述方式以增加可读性。

对于比较简单的宏可以不加该注释。

3.4.编码所使用的SourceInsight Quicker宏
为了能够规范化函数注释，以及使用doxygen自动生成对外头文件，编码要求使用的宇眼科技整理提供的source insight宏。

参见：《quicker安装和使用说明v1.1》
4.数据类型定义
4.1.标识定义
模块命名（待整理增加）：
序号模块描述模块名
1驱动bsp
2主控pmc
3消息msg
4看门狗wdt
5设备管理dev
6命令行cli
7日志log
8升级upg
9回放pb
10网页web
11通用common
12媒体media
4.2.基本数据类型
为了用户的方便，C99标准的C语言硬件为我们定义一些好用的基本数据类型，我们放心使用就可以了。

因此统一使用stdint.h头文件中定义的基本数据类型进行编程：uint8_t/uint16_t/uint32_t/uint64_t
按照posix标准，一般整形对应的*_t类型为：
1字节uint8_t
2字节uint16_t
4字节uint32_t
8字节uint64_t
typedef signed char int8_t;
typedef short int int16_t;
typedef int int32_t;
typedef long long int int64_t;
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
typedef unsigned long long int uint64_t;
规则4-1-1：宇眼科技内部使用基本数据类型必须使用以上自定义数据类型。

说明：使用自定义的数据类型，以保证不同平台下的可移植性。

规则4-1-2：必须使用sizeof获得数据类型的实际大小。

说明：由于不同的操作系统、硬件平台、不同的字节对齐方式下数据类型的大小可能发生变化，所以必须通过sizeof获得实际的大小。

例如指针的大小不能假定为4个字节，这一点在64位系统下并不成立。

4.3.数据类型命名
规则4-3-1：结构定义方式
typedef struct tagXXX_S_YYY
{
…
}XXX_S_YYY;
其中：XXX为模块名，为大写。

YYY为体现该结构含义的名字，可以有多个单词缩写及下划线组成，为大写。

注意：由于枚举和布尔类型不能保证一定是32位整数，所以为了确保结构是4字节对齐的，要求结构中不要直接使用枚举和布尔类型，而是使用明确的数据类型，一般将枚举和布尔类型用VOS_INT32代替（一般系统默认的枚举类型为int），并且必须在注释中说明对应的枚举类型。

注：为兼容不同硬件环境，要求定义结构时一定要设计成4字节对齐，不能对齐的要增加补齐的成员定义。

说明：函数定义时如果涉及到枚举类型的参数，为了与结构中的类型保持一致，也应该采用与结构中相同的原型进行定义，以减少不必要的类型转换。

规则4-3-2：联合定义方式
typedef union tagXXX_U_YYY
{
…
}XXX_U_YYY;
其中：XXX为组件，为大写。

YYY为体现该联合含义的名称，可以有多个单词缩写及下划线组成，为大写。

注意：由于枚举和布尔类型不能保证一定是32位整数，所以为了确保结构是4字节对齐的，要求结构中不要直接使用枚举和布尔类型，而是使用明确的数据类型，一般将枚举和布尔类型用VOS_UINT32代替（一般系统默认的枚举类型为int），并且必须在注释中说明对应的枚举类型。

规则4-3-3：枚举定义方式（要求都采用大写方式）
typedef enum tagXXX_E_YYY
{
XXX_E_YYY_AAA=0,
XXX_E_YYY_BBB,
…
XXX_E_YYY_BUTT
}XXX_E_YYY;
其中：XXX为组件，为大写。

YYY为体现该枚举含义的名称，可以有多个单词缩写及下划线组成，为大写。

枚举定义时，必须明确给出第一个枚举值的值，即便是0也明确给出。

规则4-3-4：函数指针定义方式
XXX_FN_YYY
其中：XXX为模块名，为大写。

YYY为体现该函数含义的名称，可以有多个单词缩写及下划线组成，为大写。

示例：typedef VOS_VOID(*PLY_FN_VOD_OPEN)();
规则4-3-5：宏定义方式
XXX_D_YYY
其中：XXX为模块名，为大写。

YYY为体现该宏含义的名称，可以有多个单词缩写及下划线组成，为大写。

示例：
#define PLY_D_MAX_URL_LEN128
对于定义的复杂内容，需要将内容用括号括起来，如
#define PLY_D_MAX_FILE_LEN(PLY_D_PATH_LEN+PLY_D_FILE_LEN)
5.标识符命名
规则5-1-1：标识符的命名，宇眼科技内部命名惯例采用小写字母惯例。

说明：所有变量都采用小写字母+下划线的方式；指针加_ptr的尾缀。

示例：
Int8_t*sys_cfg_ptr,sys_cfg;
规则5-1-2：使用前缀来区分变量的作用范围，全局变量的前缀为g_，全局的静态变量为s_，局部变量不加前缀。

示例：
uint32_t g_sys_status;/*全局变量*/
static uint16_t s_sys_status;/*全局的静态变量*/
static uint16_t sys_status;/*局部的静态变量不需要加前缀*/
规则5-1-3：全局变量加入模块名以避免重名。

示例：
uint8_t*g_pmc_revbuf;/*其中pmc为模块名*/
uint32_t g_dev_number;/*其中dev为模块名*/
6.缩进
缩进统一使用4个空格。

TAB键拓展成4个空格实现。

7.行长度限制
行长度的限制是80列，这是一个强烈推荐的限制。

超过80列的语句将被分成合理的块，除非超过80列会显著提高可读性，而且不会隐藏信息。

8.放置大括号和空格
在C样式中经常出现的另一个问题是大括号的位置。

选择一种放置策略而不选择另一种的技术原因很少，但是首选的方法是
先知Kernighan和Ritchie告诉我们，要把左括号放在最后，然后把右括号放在前面。

比如：
if(x is true){
we do y
}
这适用于所有非函数语句块，if,switch,for,while,do。

switch(action){
case KOBJ_ADD:
return"add";
case KOBJ_REMOVE:
return"remove";
case KOBJ_CHANGE:
return"change";
default:
return NULL;
}
但是，有一种特殊情况，即函数:在下一行的开头有一个大括号，因此:
int function(int x)
{
body of function
}
上面的这种函数书写方式是正确的写法。

9.空格
在(大多数)关键字之后使用空格。

比如：if/while/do/case/else等。

在大多数二进制和三元运算符的左右(两边)使用一个空格，
例如:
=+-<>*/%|&^<=>===!=?:
10.函数定义规范
10.1.命名
规则6-1-1接口函数命名:xxx_yyy
其中：xxx为模块名，yyy为体现该函数含义的名称，采用全小写的方式。

示例：
void*play_open();
uint32_t web_send_data(uint8_t*data,uint32_t len);
10.2.宏与函数
建议6-3-1：对较为短小的和时间关键性很强的函数，可以用宏代替以提高性能。

因为宏和函数在处理方式上的不同（宏是代码拷贝，函数是调用返回，以及考虑到函数调用的时间开销）,宏在处理效率上要高一些。

10.3.错误处理
本节所指“错误”包括两类：一类为由于外部输入（主要指函数参数）引起的错误，另一类为超过系统处理能力时引发的错误。

规则6-4-1：对于可能发生错误的函数，需要返回错误码，而不是通过特殊值表示错误。

说明：这样做是为了使含义明确，同时便于扩充。

示例：
int32_t pmc_get_sys_status(int32_t*state);
正常运行时返回GCP_OK，发生错误时返回错误码。

例外情况：如果确定不可能发生错误的情况下（或不需要区分错误码，即错误码单一）、或者是类似malloc这样本来是进行指针分配，并且不会关注什么错误导致分配失败的情况下，允许通过返回值作为输出。

规则6-4-2：接口函数必须检查函数所有参数输入的有效性。

说明：由于函数的外部使用者可能传入错误的参数值，为了提高程序的健壮性，必须检查参数的合法性。

如果输入了非法参数，函数应该进行相关错误处理。

错误处理的手段包括错误报告、记录错误码以及将错误码作为返回值返回。

另外，该规则也适用于检查外部文件、数据库等内容的合法性，而不能假定其内容是正确的。

对于公司外部提供的接口，在不清楚外部模块接口是否进行保护处理的情况下，调用者应该保证参数合法，不能完全依赖外部。

规则6-4-3：为提高效率，内部函数可以不检查参数合法性，由使用者保证传入合法参数。

规则6-4-4：错误码按照如下规则编制
|----------------------------------------------------------|
|MODULE_ID|SUB_MODULE_ID|ERR_ID|
|----------------------------------------------------------|
|<----8bits---->|<----8bits---->|<---------16bits--------->|
其中：
MODULE_ID代表一个组件，如播放器、呼叫，采用HCS_E_MODULE_ID中定义的模块名。

SUB_MODULE_ID代表组件内部的模块，在组件内部自行统一定义。

ERR_ID代表模块中的错误信息标识。

在头文件”hcs_base.h”中MODULE_ID定义如下：
typedef enum tagHCS_E_MODULE_ID
{
HCS_E_MODULE_ID_BASE=0x10,
HCS_E_MODULE_ID_DESK,/*1.桌面DESK*/ HCS_E_MODULE_ID_ADDR,/*2.通讯录引擎ADDR*/ HCS_E_MODULE_ID_ADDRUI,/*3.通讯录界面ADDRUI*/ HCS_E_MODULE_ID_REG,/*4.通话记录引擎REG*/ HCS_E_MODULE_ID_REGUI,/*5.通话记录界面REGUI*/ HCS_E_MODULE_ID_CONF,/*6.本地配置管理界面CONF*/ HCS_E_MODULE_ID_HINTUI,/*7.辅助部分界面HINTUI*/ HCS_E_MODULE_ID_CALLUI,/*8.通话控制界面CALLUI*/ HCS_E_MODULE_ID_DRV,/*9.OS/驱动DRV*/ HCS_E_MODULE_ID_BOOT,/*10.系统启动BOOTLOADER*/ HCS_E_MODULE_ID_BIOS,/*11.系统BIOS软件*/
HCS_E_MODULE_ID_MSYS,/*12.最小系统*/
HCS_E_MODULE_ID_MCU,/*13.MUC软件*/
HCS_E_MODULE_ID_TOOL,/*14.开发工具*/
HCS_E_MODULE_ID_ENV,/*15.软件环境*/
HCS_E_MODULE_ID_CALL,/*16.呼叫子系统*/
HCS_E_MODULE_ID_MPROC,/*17.媒体处理*/
HCS_E_MODULE_ID_PMC,/*18.主控*/
HCS_E_MODULE_ID_UPG,/*19.升级*/
HCS_E_MODULE_ID_LOG,/*20.日志*/
HCS_E_MODULE_ID_CMD,/*21.命令行*/
HCS_E_MODULE_ID_CFMG,/*22.配置管理*/
HCS_E_MODULE_ID_LOAD,/*23.加载*/
HCS_E_MODULE_ID_PPPOE,/*24.PPPOE*/
HCS_E_MODULE_ID_DHCP,/*25.DHCP*/
HCS_E_MODULE_ID_SNTP,/*26.SNTP*/
HCS_E_MODULE_ID_DNS,/*27.DNS*/
HCS_E_MODULE_ID_HTTP,/*28.HTTP*/
HCS_E_MODULE_ID_GUI,/*29.MiniGUI*/
HCS_E_MODULE_ID_DEV,/*30.设备管理*/
HCS_E_MODULE_ID_MSG,/*31.消息管理*/
HCS_E_MODULE_ID_BRW,/*32.浏览器*/
HCS_E_MODULE_ID_TEST,/*33.装备/调测*/
HCS_E_MODULE_ID_MDEV,/*34.media*/
HCS_E_MOUDLE_ID_PLAYER,/*35.player*/
HCS_E_MODULE_ID_NET,/**/
HCS_E_MODULE_ID_ZERO,/*37.零配置*/
HCS_E_MODULE_ID_CWMP,/*38.cwmp网管*/
HCS_E_MODULE_ID_BUTT,/*结尾的标志*/
HCS_E_MODULE_ID_ALL=0xff/*255.所有模块*/
}HCS_E_MODULE_ID;
在头文件”hcs_base.h”中统一的错误码宏定义如下：
#define MC_D_ERR_DEF(sysid,mid,errid)\
(((sysid)<<24)|((mid&0xff)<<16)|(errid&0xffff))
（具体参见实际头文件hcs_base.h）
规则6-4-5：错误码命名规则如下:
错误码一般采用枚举的形式定义在各模块的头文件中，为了方便管理和阅读，
错误码应该采用如下形式命名：
XXX_E_ERR_YYY_REASON
【XXX】代表组件的名称，例如PLY。

【YYY】代表该模块的名称，例如RTP；如果组件中没有细分模块，可以省去YYY。

【REASON】代表具体的原因，可以有多个大写单词组成，每个单词之间用下划线隔开，例如ALLOC_MEM_FAIL,BAD_ARGUMENT。

错误码的定义应该全部采用大写，并且子模块内部已0起始，示例：
typedef enum tagXXX_E_ERR_YYY
{
/*XXX组件的YYY模块错误码*/
/*先定义XXX组件YYY模块错误码的起始值*/
XXX_E_ERR_YYY_TOP=MC_D_ERR_DEF(HCS_E_MOUDLE_ID_XXX,YYY_MID,0),
XXX_E_ERR_YYY_REASON,
…
/*XXX组件的其他模块错误码*/
…
XXX_E_ERR_YYY_BUTT
}E_ERR_XXX;
其中，HCS_E_MOUDLE_ID_XXX为XXX组件的MODULE ID，YYY_MID为XXX组件YYY模块的模块ID，在XXX组件内部统一定义。

11.调试信息规范
11.1.调试接口定义
规则8-1-1：各个子系统都必须统一调用宇眼科技的调试信息接口，并且各模块必须定义自己的调试宏指向统一的调试函数，不允许自定义调试信息接口，通过MC_DEBUG_ON编译宏可以裁减调试信息。

下
面介绍调试信息接口的使用：
1.设置调试信息输出级别的接口：
VOS_INT32common_set_debug_level(HCS_E_MODULE_ID enSysId,
MC_E_DEBUG_LEVEL enLevel,
VOS_INT32bOutSwitchOn);
系统启动后，缺省情况应该是调试开关都关闭，所以系统启动时应该调用MC_SetDebugLevel()接口将其调试开关都关闭.
设置调试开关的示例：
/*打开呼叫模块所有的调试信息输出开关*/
common_set_debug_level(HCS_E_MODULE_ID_CALL,MC_E_DEBUG_LEVEL_ALL,VOS_TRUE);
/*关闭呼叫模块所有的调试信息输出开关*/
common_set_debug_level(HCS_E_MODULE_ID_CALL,MC_E_DEBUG_LEVEL_ALL,VOS_FALSE);
/*打开呼叫模块错误级别的调试开关*/
common_set_debug_level(HCS_E_MODULE_ID_CALL,MC_E_DEBUG_LEVEL_ERROR,VOS_TRUE);
/*关闭呼叫模块错误级别的调试开关*/
common_set_debug_level(HCS_E_MODULE_ID_CALL,MC_E_DEBUG_LEVEL_ERROR,VOS_FALSE);
2.输出调试信息的接口
#define MC_D_DEBUG(enModId,enLevel,format...)\
MC_Print(enModId,enLevel,VOS_TRUE,__FUNCTION__,__LINE__,##fmt)示例：
/*呼叫模块必须按如下方式定义输出错误调试信息，必须定义INFO、WARN、ERROR、CRIT4个界别*/
#define CALL_D_INFO(fmt...)\
MC_D_DEBUG(HCS_E_MODULE_ID_CALL,MC_E_DEBUG_LEVEL_INFO,fmt)
#define CALL_D_WARNING(fmt...)\
MC_D_DEBUG(HCS_E_MODULE_ID_CALL,MC_E_DEBUG_LEVEL_WARNING,fmt)
#define CALL_D_ERROR(fmt...)\
MC_D_DEBUG(HCS_E_MODULE_ID_CALL,MC_E_DEBUG_LEVEL_ERROR,fmt)
#define CALL_D_CRIT(fmt...)\
MC_D_DEBUG(HCS_E_MODULE_ID_CALL,MC_E_DEBUG_LEVEL_CRIT,fmt)
/*按如下方式调用*/
CALL_D_DEBUG_INFO("reg fail[ret=%d]\r\n",ret)
规则8-1-2：每个模块的调试开关和级别必须可以通过命令行进行设置，命令行统一提供，格式要求如下：set debug模块名调试级别调试开发
子系统名：call/ply等
调试级别：all/crit/error/warning/info
调试开关：on/off
呼叫子系统的命令行格式：
set debug call error on
set debug call error off
set debug call all on
set debug call all off
规则8-1-3：正式代码中，除了调试模块初始化以前的启动过程的打印以外，严禁使用printf或fprintf之类的函数进行输出。

正式代码不允许保留开发者为调试问题加入的临时调试信息。

规则8-1-4：为了方便系统维护和问题定位，系统运行过程中，如出现致命或严重的错误需要调用调试信息输出接口输出相应级别的调试信息，输出地调试信息应该能有效地指导开发人员定位问题，但
要避免高频率地输出某一调试信息。

建议8-1-5：为了方便系统维护和问题定义，系统在关键阶段点（例如初始化成功，打开成功，连接成功等）应该输出提示级别的调试信息，输出地调试信息应该能有效地指导开发人员定位问题，但要避免高频率地输出某一调试信息。

12.消息类型定义规范
TSP进程间通信采用VTOP的消息管理系统，消息头部定义遵循VTOP规定，消息体组织遵循如下规范：
规则9-1：模块、组件发送消息的消息体采用统一的格式进行组织：
其中：
消息ID：即消息类型，用于标识消息的种类。

版本号：消息体结构组织关系的版本标识，用于处理后续参数列表差异过大，应用处理过于复杂的情况。

参数列表：个数可根据需要变化，而且顺序不固定，这样有利于不同的版本或应用对参数列表的兼容处理和扩展。

例如：版本1.00使用了参数A、B、C，而版本2.00通信时增加了参数D，参数D是可选的，这样子版本2.00的程序可以处理只有参数A、B、C的版本1.00的协议。

序号：消息用于标识消息的流水号，发送者保证其唯一性和递增性，接受者可以据此进行消息丢失判断或者消息重组。

返回值：保留，暂不使用。

规则9-2：消息ID命名规范：<module>_E_MSG_<submodule>_<action>
说明：在消息定义处的注释中，需要明确说明消息是同步还是异步的，消息参数如何。

示例：
消息定义消息描述
CALL_E_MSG_ACCEPTCAL
异步消息，接受呼叫，无参数
L
CALL_E_MSG_MAKECALL异步消息，发起呼叫，消息参数参见
CALL_CTRL_S_CALL_MARK
规则9-2消息ID值按照如下规则编制：
|----------------------------------------------------------|
|MODULE_ID|SUB_MODULE_ID|MSG_ID|
|----------------------------------------------------------|
|<----8bits---->|<----8bits---->|<---------16bits--------->|
其中：
MODULE_ID代表一个组件，如播放器、呼叫，采用HCS_E_MODULE_ID中定义的模块名。

SUB_MODULE_ID代表组件内部的模块，在组件内部自行统一定义。

MSG_ID代表模块中的错误信息标识。

在头文件”hcs_base.h”中定义了MODULE_ID，该ID定义和错误处理中定义一致。

在头文件”hcs_base.h”中统一的错误码宏定义如下：
#define MC_D_MSG_DEF(sysid,mid,msgid)\
(((sysid)<<24)|((mid&0xff)<<16)|(msgid&0xffff))
（具体参见实际头文件hcs_base.h）
/*消息通信主控进程名字*/
进程定义消息通信名称说明缩写
HCS_PMC_PNAME sysm主控PMC
HCS_DEV_PNAME dev设备管理DEV
HCS_PLY_PNAME player播放器PLY
HCS_CMD_PNAME cli命令行CLI
HCS_GUI_PNAME minigui MiniGUI GUI
HCS_SPS_PNAME wsi浏览器BRW
HCS_UPG_PNAME upgrd升级UPG
HCS_PPPOE_PNAME pppoe PPPoE client PPP
HCS_HINT_PNAME hint提示信息HNT
HCS_DHCP_PNAME dhcpc DHCP client DHP
HCS_SNTPC_PNAME sntpc SNTP client SNP
HCS_GAME_PNAME game Game client GAM
HCS_GAMECTRL_PNAME gamectrl游戏主控进程GMC
HCS_DESK_PNAME hcs_desk桌面进程DSK
HCS_CALL_PNAME hcs_call呼叫进程CLL
MPR
HCS_MPROC_PNAME mproc呼叫媒体处理进程
名
13.组件裁剪和配置规范
建议10－1-1为了能满足不同版本的差异化需求，尽量满足一个版本维护多个不同特性，特性开关不建议使用宏开关的方式。

开发人员不得私自定义特性宏，如果有这样的情况，需要提出项目组、SE讨论后确定特性裁剪方式。

14.其它
规则13-1-1：所有的函数都需要显示用return返回。

规则13-1-2：条件判断时，对于数值和指针必须显示的判断等于或不等于某值，提高可读性。

规则13-1-3：每个有错误码的函数调用都应该判断一下返回值，如果实在觉得没有必要判断返回值的，需要已注释形式进行说明，表明自己已经考虑过是否需要处理返回值，对于pclint有告警的，必须通过增加void说明或其他方式消除告警。

另外，对于sprintf这样的函数已有默认的使用规则，可不说明。

建议13-1-5：统一使用CHM格式的用户手册，此条建议遵循13-1-6进行具体实施即可。

规则13-1-6：函数头说明要求：
(1)新开发的代码，所有函数头都要按照doxygen语法模版进行说明。

(2)每个函数定义前必须有函数说明。

(3)为减少同步工作量，内部函数声明前不需要函数说明，外部接口函数声明前部需要函数说明。