联通项目组编程规范Word文件下载.docx
《联通项目组编程规范Word文件下载.docx》由会员分享,可在线阅读,更多相关《联通项目组编程规范Word文件下载.docx(47页珍藏版)》请在冰豆网上搜索。
m_iMax表示一个整形的成员最大值变量
✧指针类型
p+标识符
字符串类型:
s+标识符
✧指向指针的变量
pp+标识符
✧常量类型
c+标识符
2.2联通项目专业术语标识符
标识符命
类型
含义
user_no
Varchar2(21)
用户号码
user_id
Number(15)
用户id
city
Varchar2(6)
城市代码
area
Varchar2(10)
地区代码
county
区县代码
corpid
Varchar(10)
分销商代码
inid
Number(3)
scp编号
hlrid
hlr编号
maintag
Number
(1)
主品牌
thirdtag
次品牌
subtag
Number
(2)
子品牌
retn
Number
执行结果
ret_code
错误码
desc
Varchar2(512)
描述
dinner_name
套餐名
Dinner_type
Varchar2(20)
套餐类型
dinner_status
套餐状态
begin_stamp
Varchar2(16)
套餐生效时间
end_stamp
套餐结束时间
balance
用户余额
hot
亲密热友,私密热信号码
submittime
date
记录递交时间
Handletime
Date
记录处理时间
第3章注释
良好的注释风格,对于代码的可读性和后续维护性基极重要。
因此有必要对注释风格进行一个规范。
一般情况下源程序有效注释量必须在%20以上。
3.1文件头注释
文件头注释包含版权和版本的声明,位于头文件和定义文件的开头(参见示例2-1),主要内容有:
(1)版权信息。
(2)文件名称,标识符,摘要。
(3)主要函数及功能
(4)当前版本号,作者/修改者,完成日期。
(5)版本历史信息。
例2-1:
/*
*Copyright(C)2002-2008,华工奕高科技有限公司
*Allrightsreserved.
*
*FileName:
//文件名
*Author:
Version:
Date:
//作者版本完成日期
*Description:
//简要描述本文件的内容
*FunctionList:
//主要函数列表,每条记录应包括函数名和函数功能说明
1.……
*History//修改历史记录列表应包括每次修改日期,修改者和修改内容
1Date:
Author:
Modification:
*/
3.2函数注释
函数注释包含函数目的/功能描述,入参说明,出参说明,返回值,调用关系(函数/表)等。
*Function:
//函数名
//函数功能说明
*Calls:
//被本函数调用的函数清单(可省略)
*Calledby:
//调用本函数的函数清单(可省略)
*Input:
//每个入参的作用,取值说明
*Output:
//出参说明
*Return:
//返回值说明
3.3代码注释
(1)代码注释的原则是对于重要的代码行或段落进行提示。
(2)注释是应简洁明了,是对代码的“提示”,而不是说明文档。
程序中的注释不可喧宾夺主,注释太多了会让人眼花缭乱。
注释的花样要少。
(3)边写代码边注释,修改代码同时修改相应的注释,以保证注释与代码的一致性。
不再有用的注释要删除
(4)注释应当准确、易懂,防止注释有二义性。
错误的注释不但无益反而有害
(5)注释的位置应与被描述的代码相邻,可以放在代码的上方或右方,不可放在下方
(6)尽量避免在注释中使用缩写,特别是不常用缩写。
(7)注释应考虑代码的可读性,注释与描述的内容应进行同样的缩排,如果注释有中英文,建议统一使用中文注释,除非能英文非常准确地表达。
第4章
代码可读性
4.1运算符优先级处理
使用括号明确表达运算符的优先级,避免使用默认优先级。
Word=(high<
<
4)|low
4.2源程序中关系较为紧密的代码应尽可能相邻
不好的代码风格:
rect.length=10;
char_poi=str;
rect.width=5;
良好的代码风格:
4.3除非有时有必要,不要使用难懂的技巧性很高的语句,高技巧不一定高效率
如:
*stat_poi+++=1;
应改为如下:
*stat_poi+=1;
*stat_poi++;
4.4空行
空行起着分隔程序段落的作用。
空行得体(不过多也不过少)将使程序的布局更加清晰。
空行不会浪费内存,虽然打印含有空行的程序是会多消耗一些纸张,但是值得。
所以不要舍不得用空行。
✧在每个类声明之后、每个函数定义结束之后都要加空行。
✧在一个函数体内,逻揖上密切相关的语句之间不加空行,其它地方应加空行分隔。
//空行
voidFunction1(…)
{
…
}
voidFunction2(…)
voidFunction3(…)
while(condition)
statement1;
if(condition)
statement2;
else
statement3;
statement4;
}
4.5代码行
✧一行代码只做一件事情,如只定义一个变量,或只写一条语句。
这样的代码容易阅读,并且方便于写注释。
✧if、for、while、do等语句自占一行,执行语句不得紧跟其后。
不论执行语句有多少都要加{}。
这样可以防止书写失误。
✧建议尽可能在定义变量的同时初始化该变量(就近原则)
//良好的代码风格
intwidth;
//宽度
intheight;
//高度
intdepth;
//深度
//不良的代码风格
intwidth,height,depth;
//宽度高度深度
x=a+b;
y=c+d;
z=e+f;
X=a+b;
y=c+d;
z=e+f;
if(width<
height)
dosomething();
height)dosomething();
for(initialization;
condition;
update)
other();
4.6代码行内的空格
✧关键字之后要留空格。
象const、virtual、inline、case等关键字之后至少要留一个空格,否则无法辨析关键字。
象if、for、while等关键字之后应留一个空格再跟左括号‘(’,以突出关键字。
✧函数名之后不要留空格,紧跟左括号‘(’,以与关键字区别。
✧‘(’向后紧跟,‘)’、‘,’、‘;
’向前紧跟,紧跟处不留空格。
✧‘,’之后要留空格,如Function(x,y,z)。
如果‘;
’不是一行的结束符号,其后要留空格,如for(initialization;
update)。
✧赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符,如“=”、“+=”“>
=”、“<
=”、“+”、“*”、“%”、“&
&
”、“||”、“<
”,“^”等二元操作符的前后应当加空格。
✧一元操作符如“!
”、“~”、“++”、“--”、“&
”(地址运算符)等前后不加空格。
✧象“[]”、“.”、“->
”这类操作符前后不加空格。
✧对于表达式比较长的for语句和if语句,为了紧凑起见可以适当地去掉一些空格,如for(i=0;
i<
10;
i++)和if((a<
=b)&
(c<
=d))
voidFunc1(intx,inty,intz);
//良好的风格
voidFunc1(intx,inty,intz);
//不良的风格
if(year>
=2000)//良好的风格
if(year>
=2000)//不良的风格
if((a>
=d))//良好的风格
if(a>
=b&
c<
=d)//不良的风格
for(i=0;
i++)//良好的风格
for(i=0;
i<
i++)//不良的风格
for(i=0;
I<
10;
i++)//过多的空格
x=a<
b?
a:
b;
x=a<
b?
a:
b;
//不好的风格
int*x=&
y;
//良好的风格
int*x=&
y;
//不良的风格
array[5]=0;
//不要写成array[5]=0;
a.Function();
//不要写成a.Function();
b->
Function();
//不要写成b->
Function();
4.7对齐
✧程序的分界符‘{’和‘}’应独占一行并且位于同一列,同时与引用它们的语句左对齐。
✧{}之内的代码块在‘{’右边三个空格符
良好的代码风格不良的代码风格
voidFunction(intx)
…//programcode
voidFunction(intx){
if(condition)
if(condition){
else{
update){
While(condition)
while(condition){
如果出现嵌套的{},则使用缩进对齐,如:
4.8长行拆分
✧代码行最大长度宜控制在70至80个字符以内。
代码行不要过长,否则眼睛看不过来,也不便于打印。
✧长表达式要在低优先级操作符处拆分成新行,操作符放在新行之首(以便突出操作符)。
拆分出的新行要进行适当的缩进,使排版整齐,语句可读。
if((very_longer_variable1>
=very_longer_variable12)
(very_longer_variable3<
=very_longer_variable14)
(very_longer_variable5<
=very_longer_variable16))
virtualCMatrixCMultiplyMatrix(CMatrixleftMatrix,
CMatrixrightMatrix);
for(very_longer_initialization;
very_longer_condition;
very_longer_update)
4.9类的版式
将成员函数写在前面,而将成员变量写在后面。
classA
public:
voidFunc1(void);
voidFunc2(void);
private:
inti,j;
floatx,y;
第5章变量和结构
5.1去掉没必要的公共变量。
说明:
公共变量是增大模块间耦合的原因之一,故应减少没必要的公共变量以降低模块间的耦合度。
5.2仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系。
在对变量声明的同时,应对其含义、作用及取值范围进行注释说明,同时若有必要还应说明与其它变量的关系。
5.3明确公共变量与操作此公共变量的函数或过程的关系,如访问、修改及创建等。
明确过程操作变量的关系后,将有利于程序的进一步优化、单元测试、系统联调以及代码维护等。
这种关系的说明可在注释或文档中描述。
示例:
在源文件中,可按如下注释形式说明。
RELATIONSystem_InitInput_RecPrint_RecStat_Score
StudentCreateModifyAccessAccess
ScoreCreateModifyAccessAccess,Modify
注:
RELATION为操作关系;
System_Init、Input_Rec、Print_Rec、Stat_Score为四个不同的函数;
Student、Score为两个全局变量;
Create表示创建,Modify表示修改,Access表示访问。
其中,函数Input_Rec、Stat_Score都可修改变量Score,故此变量将引起函数间较大的耦合,并可能增加代码测试、维护的难度。
5.4当向公共变量传递数据时,要十分小心,防止赋与不合理的值或越界等现象发生。
对公共变量赋值时,若有必要应进行合法性检查,以提高代码的可靠性、稳定性。
5.5防止局部变量与公共变量同名。
若使用了较好的命名规则,那么此问题可自动消除。
5.6严禁使用未经初始化的变量作为右值。
特别是在C/C++中引用未经赋值的指针,经常会引起系统崩溃。
5.7构造仅有一个模块或函数可以修改、创建,而其余有关模块或函数只访问的公共变量,防止多个不同模块或函数都可以修改、创建同一公共变量的现象。
降低公共变量耦合度。
5.8使用严格形式定义的、可移植的数据类型,尽量不要使用与具体硬件或软件环境关系密切的变量。
使用标准的数据类型,有利于程序的移植。
如下例子(在DOS下BC3.1环境中),在移植时可能产生问题。
voidmain()
registerintindex;
//寄存器变量
_AX=0x4000;
//_AX是BC3.1提供的寄存器“伪变量”
...//programcode
5.9结构的功能要单一,是针对一种事务的抽象。
设计结构时应力争使结构代表一种现实事务的抽象,而不是同时代表多种。
结构中的各元素应代表同一事务的不同侧面,而不应把描述没有关系或关系很弱的不同事务的元素放到同一结构中。
如下结构不太清晰、合理。
typedefstructSTUDENT_STRU
unsignedcharname[8];
/*student'
sname*/
unsignedcharage;
sage*/
unsignedcharsex;
ssex,asfollows*/
/*0-FEMALE;
1-MALE*/
unsignedchar
teacher_name[8];
/*thestudentteacher'
unisgnedchar
teacher_sex;
/*histeachersex*/
}STUDENT;
若改为如下,可能更合理些。
typedefstructTEACHER_STRU
/*teachername*/
unisgnedcharsex;
/*teachersex,asfollows*/
}TEACHER;
unsignedintteacher_ind;
/*histeacherindex*/
5.10不要设计面面俱到、非常灵活的数据结构。
面面俱到、灵活的数据结构反而容易引起误解和操作困难。
5.11不同结构间的关系不要过于复杂。
若两个结构间关系较复杂、密切,那么应合为一个结构。
如下两个结构的构造不合理。
typedefstructPERSON_ONE_STRU
unsignedcharaddr[40];
unsignedcharcity[15];
}PERSON_ONE;
typedefstructPERSON_TWO_STRU
unsignedchartel;
}PERSON_TWO;
由于两个结构都是描述同一事物的,那么不如合成一个结构。
typedefstructPERSON_STRU
}PERSON;
5.12结构中元素的个数应适中。
若结构中元素个数过多可考虑依据某种原则把元素组成不同的子结构,以减少原结构中元素的个数。
增加结构的可理解性、可操作性和可维护性。
假如认为如上的_PERSON结构元素过多,那么可如下对之划分。
typedefstructPERSON_BASE_INFO_STRU
}PERSON_BASE_INFO;
typedefstructPERSON_ADDRESS_STRU
}PERSON_ADDRESS;
PERSON_BASE_INFOperson_base;
PERSON_ADDRESSperson_addr;
5.13仔细设计结构中元素的布局与排列顺序,使结构容易理解、节省占用空间,并减少引起误用现象。
合理排列结构中元素顺序,可节省空间并增加可理解性。
如下结构中的位域排列,将占较大空间,可读性也稍差。
typedefstructEXAMPLE_STRU
unsignedintvalid:
1;
PERSONperson;
unsignedintset_flg:
}EXAMPLE;
若改成如下形式,不仅可节省1字节空间,可读性也变好了。
PERSONperson;
5.14结构的设计要尽量考虑向前兼容和以后的版本升级,并为某些未来可能的应用保留余地(如预留一些空间等)。
软件向前兼容的特性,是软件产品是否成功的重要标志之一。
如果要想使产品具有较好的前向兼容,那么在产品设计之初就应为以后版本升级保留一定余地,并且在产品升级时必须考虑前一版本的各种特性。
5.15留心具体语言及编译器处理不同数据类型的原则及有关细节。
如在C语言中,static局部变量将在内存“数据区”中生成,而非static局部变量将在“堆栈”中生成。
这些细节对程序质量的保证非常重要。
5.1