C++.docx
- 文档编号:4267384
- 上传时间:2022-11-28
- 格式:DOCX
- 页数:21
- 大小:31.70KB
C++.docx
《C++.docx》由会员分享,可在线阅读,更多相关《C++.docx(21页珍藏版)》请在冰豆网上搜索。
C++
C++编码规范
目录
目录2
C++编码规则6
1总则6
2命名规则6
2.1命名所用字符规则6
2.1.1变量、函数、宏命名只能由26个字母,10个数字,及下划线的一个子集来组成,不能使用“$”等符号。
6
2.1.2下划线符号‘_’不能出现在符号名头或结尾,因为这类符号名不够醒目,容易与不带下划线‘_’的符号名混淆。
6
2.1.3一个符号名中间不应出现连续两个‘_’,因为两个‘_’与一个‘_’之间的区别不明显,容易混淆。
7
2.2文件命名规则7
2.2.1文件命名考虑到与MSDOS等老的文件系统兼容,统一采用符合8.3格式的文件命名格式(即文件名不超过8位,扩展名不超过3位)。
7
2.2.2对头文件采用.h作为后缀,C的源文件采用.c作为后缀,C++的源文件以.cpp作为后缀。
7
2.2.3在此基础上规定,模块的主函数所在的文件应命名为p_xxxxxx.c或p_xxxxxx.cpp,其中p为Process的缩写,下划线后面为1~6个字母,说明该进程的功能(以下类似)。
其它类型的文件名的定义不能以p_开头,要做到最大限度地说明文件的内容。
7
2.3函数命名规则7
2.3.1函数命名采用大小写字母结合的形式。
7
2.3.2函数的首字母一般情况下建议大写,如果用来表示某一类函数时加的前缀可以小写,如fCMISGet(),qxCMISGet()。
7
2.3.3函数名的命名建议采用动宾格式。
8
2.3.4函数名中不同意义字段之间不要用下划线连接,而且要把每个字段的首字母大写以示区分。
8
2.3.5专有名词和缩写按照习惯的大小写形式嵌入函数名中,不受第一条的限制。
8
2.3.6函数命名力求清晰,明了。
通过函数名,就能够判断函数的主要处理功能。
8
2.3.7函数名的长度必须控制在30字符之内。
8
2.3.8对提供给大部分模块用的一些公用函数,如CMISE所提供的M_GET()、M_CREAT()等,不在以上规定中,建议全部用大写。
8
2.4类型的命名规则8
2.4.1结构,联合,枚举类型定义统一使用typedefstruct{…}TStructTypeName的形式,即结构名采用大小写结合的方法,在开头加上T,表明是类型定义。
9
2.4.2定义结构、联合、枚举的指针类型在类型名之前再加上P,即采用PTAgentErrorMsg的形式。
定义结构、联合、枚举的长指针在指针类型名之前再加上L,即采用LPTAgentErrorMsg的形式。
9
2.5类的定义规则9
2.5.1类名采用大小写结合的方法,在级成类名的单词之间不用下划线。
在开头加上C,表明是类(class)的定义。
类的成员变量统一在前面加m_前缀,其中m为Member的缩写。
成员函数的定义参照前面有关函数定义的规则。
10
2.6宏定义的命名规则11
2.6.1宏定义统一使用大写字母和数字,中间可以加下划线。
11
2.6.2事件的定义在前面加上EV_。
11
2.6.3常量定义中如果包含表达式,表达式需用小括号括起来。
11
2.6.4常量的定义建议加上强制类型说明。
11
2.7变量名的命名规则11
2.7.1对于全局变量,要求在变量前加g_前缀,g是global的缩写,如g_dwTimer。
11
2.7.2对于类的成员变量,要示在变量的前面加上m_前缀,m是member的缩写,如m_wIndex。
12
2.7.3变量名采用类似于匈牙利命名法的方法:
变量名最前有类型前缀,类型前缀后面是变量的含义。
变量含义采用大小写结合的办法。
12
2.7.4对于一些规范中定义的变量,如CMIP,DAP的协议数据单元中的成员,建议直接采用规范定义的名称,不必遵守上述定义。
12
2.7.5基本类型前缀定义如下(全部小写):
12
2.7.6自定义类型的变量名定义13
2.7.7类的变量名定义13
3注释的编写规则13
3.1每行注释不能超过80列。
13
3.2注释统一采用中文。
13
3.3注释可以使用标准C的/**/。
也可以采用C++的//。
一般的原则是一行注释用//,一段注释用/**/。
13
3.4每个.c文件前必须加上程序前的注释。
注释采用统一格式如下。
13
3.5对于函数头上的注释,使用以下格式:
14
3.6文件中的宏定义、结构、枚举、外部函数的说明、全局变量的说明,其右侧必须有一简单的注释,说明其作用。
14
3.7对于各函数内部代码的注释规定如下:
14
3.7.1每行只定义一个变量,每个变量定义后都要有注释,说明其作用。
14
3.7.2注释与注释作用的代码同级缩进。
15
3.7.3代码块的注释放在该代码块上面一行。
整个代码块前后与其它代码块以空行分割。
15
3.7.4对某行代码的注释,如果一行能够写下,应把注释放在该行代码之后;如果一行不能够容纳,应把注释放在代码之前,作为对代码块的注释。
15
4文件书写规范15
4.1.c文件中,组织顺序为公用头文件,自用头文件,宏,结构联合,类原型(建议放在头文件中),变量,函数原型,类的实现,函数实现的顺序进行。
15
4.2.c文件中,类的实现,先构造/析构函数,再私有函数,最后公用函数的顺序书写。
16
4.3.c文件中,函数先主函数,再子函数,先进程主体,继之进程分支,再各过程,由大到小的顺序书写。
16
4.4.h文件的组织顺序:
16
5函数编写规范16
5.1局部变量必须赋初值。
16
5.2函数定义应明确注明返回值,如果函数无返回值应明确表明void。
16
5.3函数的返回值禁止用0、1、-1等约定表明状态,要求用宏。
17
5.4函数长度不应超过200行。
如果超过200行,就应该考虑将此子函数分为几个。
太长的函数理解不容易,而且一般来说,功能也比较复杂,不容易维护。
17
5.5函数的参数不要太多,不能多于六个。
如果实在比较多,可以考虑通过传入结构的方法解决。
17
5.6函数禁止使用带有二义性的返回值。
17
5.7函数体内不能有不可到达的代码。
18
5.8声明过的变量必须被使用,没有被使用的变量应从程序中取消,以提高代码的可读性和可靠性。
18
5.9调用具有返回值的函数时,必须判断返回的结果,并根据返回值作相应处理。
18
5.10函数的参数表中所有参数的总长度不能大于40个字节,一些自定义的结构参量可以采用传递指针的方式进行参数传递,这样可以减少函数调用对系统堆栈的需求,同时防止因堆栈溢出引起的软件故障。
18
6数据类型编写规范19
6.1对于BYTE、WORD、DWORD等常用数据类型及指针的使用请参照附录A“数据类型定义”。
19
6.2尽量少用int等与具体机器相关的类型。
19
6.3对于非‘0’和‘1’的常数,应使用宏定义的常量。
19
6.4使用TRUE和FALSE作为布尔表达式结果的标识符,禁用0、1等。
19
6.5对于复杂的逻辑判断应建立中间的逻辑变量以简化代码和增加可读性;在单个if、while等判断语句中,不能有多于三个条件测试部分,且各测试部分必须使用括号括起来。
如果条件较多,建议使用中间变量,将相关部分的测试结果赋给变量。
19
6.6减少指针的强制类型转化。
如果一定要使用的话,在转换前一定要仔细思考。
19
6.7释放指针后,要把它设为NULL。
19
6.8如果指针类型明确不会改变,应该制为const类型的指针,以加强编译器的检查。
20
6.9定义变量时,每行只定义一个变量。
20
6.10定义指针类型的数据,*应放在变量前。
20
7条件、循环、switch语句编写规范21
7.1不要使用过多的嵌套,嵌套层次不能超过4层。
如果超过4层,应考虑重新设计程序。
21
7.2低一级的程序块比上一级的代码块退后4个空格,同级程序段代码位置平齐。
不要使用tab键对齐代码,一定要使用空格键。
编辑时可以把一个tab键设成4个空格,然后把tab键用空格键代替。
建议采用能自动对齐格式的编辑器(如MicrosoftVisualC++)。
21
7.3括号“{”、“}”独立使用一行,但注释可以写在同一行,“{”放在if,while,switch的下一行,与if,while,switch对齐。
”}”与“{”对齐。
21
7.4无论ifelse、for、while的程序块的长度为一行还是超过一行,都要用{}把程序块分割。
21
7.5建议初始化循环的代码紧放在循环前,加强代码的可读性和可维护性。
21
7.6条件判断语句内不能有赋值语句,如if(x=y),这类语句不够明确,容易引起混淆。
21
7.7条件判断语句内不能有函数调用,如if(Func1()),这种程序不便于调试。
21
7.8if、while等条件判断必须明确使用<,<=,>=,>,==,!
=等判断符号,即不能使用if(byPara),if(!
byPara)类似的表达式。
22
7.9for循环语句内的计数器不能在循环体内被修改,同时,它必须是局部变量,这样将减少出错的危险,并提高程序的可读性。
22
7.10在代码中,先按正常情况的路径往下写,然后再写异常情况。
应该把正常情况放在if后面而不是else后面。
如果先写异常情况,再写正常情况有利于代码简化和提高可读性,可以不采用这条原则,但是要在该段代码块的注释中说明。
22
7.11在switch-case语句中,case语句最后必须用break显式地标明结束,若要继续执行下一条语句,一定要进行注释说明不用break结束的理由,default不能忽略,其后要加入异常处理。
22
7.12switch语句的每个分支里的语句数一般应少于30行,以提高程序的可读性。
否则考虑采用函数调用。
特殊情况例外。
22
7.13禁止程序员自己编写死循环,统一使用操作系统提供的用宏写的死循环。
22
7.14建议不使用i,j,k作为循环的控制变量,应采用更有意义的变量。
22
8其他23
8.1不同逻辑程序块之间使用空行分隔。
23
8.2各类运算符两侧均需加上至少一个空格。
23
8.3相关的赋值语句的等号对齐。
23
8.4每行仅写一条语句。
23
8.5禁止语句连等。
23
8.6一行代码不允许超过80列。
23
8.7若函数的传入参数处理不当,会产生较严重后果时,必须对参数的合法性进行必要的检查。
23
8.8使用new,new[],delete,delete[]操作符来分配和回收内存,不要使用malloc(),free()函数进行类似操作。
23
8.9尽量少用goto语句,但如果使用goto语句可以使处理变的更加简单时,可以考虑使用。
23
8.10断言的使用:
23
9附录24
9.1其它说明24
9.2版本背景介绍24
9.3评审记录24
C++编码规则
1总则
后台软件编码主要考虑以下原则:
●软件系统的模块化设计原则
●软件系统的稳定性、易读性、可修改性、可扩充性和可重用性
●软件系统的可移植性
●中兴软件系统的结构及其特点
本规范中所指的编程是指根据SDL流程图或其它流程图,通过人工方式用高级语言如C/C++语言来实现该流程图的过程。
本规范的作用范围为后台的C/C++编程部分,如Sun、NT等,前台部分不在作用范围内。
本规范在充分遵循以上原则的基础之上,定义了在编程过程中文件的命名规则,程序的编排格式、函数名、类型、宏、变量、类名、类的成员变量的命名规则、注释的书写规范和C/C++语言的编码规则。
2命名规则
2.1命名所用字符规则
2.1.1变量、函数、宏命名只能由26个字母,10个数字,及下划线的一个子集来组成,不能使用“$”等符号。
2.1.2下划线符号‘_’不能出现在符号名头或结尾,因为这类符号名不够醒目,容易与不带下划线‘_’的符号名混淆。
2.1.3一个符号名中间不应出现连续两个‘_’,因为两个‘_’与一个‘_’之间的区别不明显,容易混淆。
2.2文件命名规则
2.2.1文件命名考虑到与MSDOS等老的文件系统兼容,统一采用符合8.3格式的文件命名格式(即文件名不超过8位,扩展名不超过3位)。
2.2.2对头文件采用.h作为后缀,C的源文件采用.c作为后缀,C++的源文件以.cpp作为后缀。
2.2.3在此基础上规定,模块的主函数所在的文件应命名为p_xxxxxx.c或p_xxxxxx.cpp,其中p为Process的缩写,下划线后面为1~6个字母,说明该进程的功能(以下类似)。
其它类型的文件名的定义不能以p_开头,要做到最大限度地说明文件的内容。
2.3函数命名规则
2.3.1函数命名采用大小写字母结合的形式。
2.3.2函数的首字母一般情况下建议大写,如果用来表示某一类函数时加的前缀可以小写,如fCMISGet(),qxCMISGet()。
2.3.3函数名的命名建议采用动宾格式。
【例】
GetCount()、SetTag()、GetMOAttribute()等。
2.3.4函数名中不同意义字段之间不要用下划线连接,而且要把每个字段的首字母大写以示区分。
2.3.5专有名词和缩写按照习惯的大小写形式嵌入函数名中,不受第一条的限制。
【例】
ROInvoke()、CMISEInit()、SetRDN()等。
2.3.6函数命名力求清晰,明了。
通过函数名,就能够判断函数的主要处理功能。
【好的示例】
SetScopeBaseMO()
【不好的示例】
SetAbc()
2.3.7函数名的长度必须控制在30字符之内。
2.3.8对提供给大部分模块用的一些公用函数,如CMISE所提供的M_GET()、M_CREAT()等,不在以上规定中,建议全部用大写。
2.4类型的命名规则
2.4.1结构,联合,枚举类型定义统一使用typedefstruct{…}TStructTypeName的形式,即结构名采用大小写结合的方法,在开头加上T,表明是类型定义。
【好的示例】
typedefstructtagAgentErrorMsg{
BYTEErrorNo;
CHARErrorMsg[MAX_ERROR_MSG_LEN];
}TAgentErrorMsg;
【不好的示例】
typedefstucttag_agent_error_msg{
BYTEErrorNo;
CHARErrorMsg[MAX_ERROR_MSG_LEN]
}AgentErrorMsg;
typedefstucttagAGENTERRORMSG{
BYTEErrorNo;
CHARErrorMsg[MAX_ERROR_MSG_LEN]
}AGENTERRORMSG;
2.4.2定义结构、联合、枚举的指针类型在类型名之前再加上P,即采用PTAgentErrorMsg的形式。
定义结构、联合、枚举的长指针在指针类型名之前再加上L,即采用LPTAgentErrorMsg的形式。
2.5类的定义规则
2.5.1类名采用大小写结合的方法,在级成类名的单词之间不用下划线。
在开头加上C,表明是类(class)的定义。
类的成员变量统一在前面加m_前缀,其中m为Member的缩写。
成员函数的定义参照前面有关函数定义的规则。
【好的示例】
classCSampleClass{
private:
WORDm_wValue;
public:
WORDGetValue()const;
voidSetValue(constWORDwValue);
};
【不好的示例】
classSampleClass{
private:
WORDValue;
public:
WORDGetValue();
voidSetValue(constWORDnewValue);
};
classC_sample_class{
private:
WORDm_wValue;
public:
WORDGetValue();
voidSetValue(constWORDnewValue);
};
2.6宏定义的命名规则
2.6.1宏定义统一使用大写字母和数字,中间可以加下划线。
【好的示例】
#defineTRUE1
【不好的示例】
#defineTrue1
2.6.2事件的定义在前面加上EV_。
【好的示例】
EV_MOGETEVENT
【不好的示例】
mo_get_event。
MO_GET_EVENT
2.6.3常量定义中如果包含表达式,表达式需用小括号括起来。
2.6.4常量的定义建议加上强制类型说明。
【好的示例】
#defineMOCREATE(WORD)1004
【不好的示例】
#defineMOCREATE1004
2.7变量名的命名规则
2.7.1对于全局变量,要求在变量前加g_前缀,g是global的缩写,如g_dwTimer。
2.7.2对于类的成员变量,要示在变量的前面加上m_前缀,m是member的缩写,如m_wIndex。
2.7.3变量名采用类似于匈牙利命名法的方法:
变量名最前有类型前缀,类型前缀后面是变量的含义。
变量含义采用大小写结合的办法。
【好的示例】
DWORDdwCount;
【不好的示例】
DWORDdwabd;
DWORDdw_count;
DWORDcount;
2.7.4对于一些规范中定义的变量,如CMIP,DAP的协议数据单元中的成员,建议直接采用规范定义的名称,不必遵守上述定义。
2.7.5基本类型前缀定义如下(全部小写):
基本类型
意义
b
Boolean布尔
by
Byte字节
ch
Char字符
w
不带符号的Word字
dw
不带符号的Doubleword字符
sw
带符号的16位整数
sdw
带符号的32位整数
f
单精度浮点数
sz
以NULL终结的字符
t
自定义类型
c
Class类
基本类型前缀之前可以按需要加上以下的公共前缀。
公共前缀
意义
a
数组
p
指针
lp
长(远)指针
np
近指针
2.7.6自定义类型的变量名定义
自定义类型的变量统一加前缀t,t在g_或m_前缀之后,如g_tMsg;
2.7.7类的变量名定义
类的变量命名应能尽量体现其功能含义和类型,采用类型结合加西文含义的命名规则,其前缀表示类的缩写(缩写原则上采用去元音方式),随后的每一单词(或单词缩写)的首字母为大写,如cstrName,cattrCellId;宁可名字写得较长也要避免含义模糊。
对于一些常用的类,在开发阶段再做具体的缩写规定。
3注释的编写规则
3.1每行注释不能超过80列。
3.2注释统一采用中文。
3.3注释可以使用标准C的/**/。
也可以采用C++的//。
一般的原则是一行注释用//,一段注释用/**/。
3.4每个.c文件前必须加上程序前的注释。
注释采用统一格式如下。
/******************************************************************************
模块名:
文件名:
相关文件:
文件实现功能:
作者:
版本:
---------------------------------------------------------------------------------------------------------------------
修改记录:
日期版本修改人修改内容
09/15/20111.0某某------------
******************************************************************************/
注释中的各个字段要用空格键对齐,不要用tab键对齐。
在编辑代码时可以设置编辑器的tab键用空格键代替。
如果代码文件比较独立,注释中的“相关文件”可以空缺。
当代码相对比较稳定后,任何代码修改都应该加在修改纪录中。
3.5对于函数头上的注释,使用以下格式:
/*====================================================================
函数名:
功能:
算法实现:
(可选项)
引用全局变量:
输入参数说明:
返回值说明:
====================================================================*/
对于实现比较复杂的函数或主要功能函数,程序员应该加上“算法实现”部分。
每个函数都应该在此处详细注释说明其输入输出参数的含义和取值范围。
如果输入输出参数是结构或者结构指针,则要说明其中本函数中要用到的各个域的含义和取值范围。
对于引用的全局变量和影响到的全局变量,也要采取和输入输出相同的办法进行注释。
3.6文件中的宏定义、结构、枚举、外部函数的说明、全局变量的说明,其右侧必须有一简单的注释,说明其作用。
【好的示例】
#defineMAX_ERROR_MSG_LEN(BYTE)20/*出错信息字符串的最大长度*/
【不好的示例】
#defineMAX_ERROR_MSG_LEN(BYTE)20
3.7对于各函数内部代码的注释规定如下:
3.7.1每行只定义一个变量,每个变量定义后都要有注释,说明其作用。
【好的示例】
DWORDdwSendCount;/*发送个数*/
DWORDdwReceiveCount;/*接收个数*/
【不好的示例】
DWORDdwSendCount,dwReceiveCount;/*发送和接收的个数*/
3.7.2注释与注释作用的代码同级缩进。
【好的示例】
/*判断是否成功*/
if(bFinish==TRUE)
……
【不好的示例】
/*判断是否成功*/
if(bFinish==TRUE)
3.7.3代码块的注释放在该代码块上面一行。
整个代码块前后与其它代码块以空行分割。
【好的示例】
Codestate
【空行】
/*在表中查询*/
Codeblock
【空行】
3.7.4对某行代码的注释,如果一行能够写下,应把注释放在该行代码之后;如果一行不能够容纳,应把注释放在代码之前,作为对代码块的注释。
【好的示例】
dwCount=0;/*次数统计置为0*/
4文件书写规范
4.1.c文件中,组织顺序为公用头文件,自用头文件,宏,结构联合,类原型(建议放在头文件中),变量,函数原型,类的实现,函数实现的顺序进行。
4.2
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- C+
![提示](https://static.bdocx.com/images/bang_tan.gif)