软件开发代码标准C语言.docx
- 文档编号:28996499
- 上传时间:2023-07-20
- 格式:DOCX
- 页数:22
- 大小:25.85KB
软件开发代码标准C语言.docx
《软件开发代码标准C语言.docx》由会员分享,可在线阅读,更多相关《软件开发代码标准C语言.docx(22页珍藏版)》请在冰豆网上搜索。
软件开发代码标准C语言
XX产品研究部
文档编号
产品版本
密级
开发适用
共页
收文:
XX产品研究部软件开发人员
软件开发代码规范
(仅供内部使用)
拟制:
周超
日期:
2011-5-11
审核:
日期:
核准:
日期:
签发:
日期:
文档版本:
V0.11
文件修改记录
修改日期
版本
修改页码、章节、条款
修改描述
作者
2011-4-29
0.1
创建初稿
周超
2011-5-11
0.11
3.3数据注释
4.3类型命名
4.4变量命名
4.6函数命名
1)修改3.4数据注释【规则3-4-3】全局变量注释例子
2)在“4.3类型命名”、“4.4变量命名”、“4.6函数命名”中,增加对前缀、关键缩写词等可以适当全部大写的处理。
周超
第一章原则
本文档的目的是提供一个公共的编码规范。
这个规范详细阐述在编码时要怎样写、不要怎样写,旨在提高代码的可读性、可维护性,使代码易于管理,使所有人可以集中精力去实现内容,而非处理各种复杂的表现形式。
使代码易于管理的方法之一是增强代码一致性,让别人可以读懂你的代码是很重要的,保持统一编程风格意味着可以轻松根据“模式匹配”规则推断各种符号的含义。
创建通用的、必需的习惯用语和模式可以使代码更加容易理解。
虽然在某些情况下改变一些编程风格可能会是好的选择,但我们还是应该遵循一致性原则,尽量不这样去做。
关键在于保持一致。
第二章排版
2.1空行
●【规则2-1-1】在每个函数、结构体、枚举定义结束之后都要加空行。
●【规则2-1-2】在一个函数体内,逻辑密切相关的语句之间不加空行,其它地方应加空行分隔。
structst1
{
…
};
//空行
enum
{
…
};
//空行
voidFunction1(…)
{
…
}
//空行
voidFunction2(…)
{
…
}
//空行
while(condition)
{
statement1;
//空行
if(condition)
{
statement2;
}
else
{
statement3;
}
//空行
statement4;
}
函数之间的空行函数内部的空行
●【规则2-1-3】相对独立的程序块之间、变量说明之后必须加空行。
if(!
is_lock_card_succ)
{
...//programcode
}
GetLockPhoneInfo(&st_lock_phone_info);
if(!
is_lock_card_succ)
{
...//programcode
}
//空格
GetLockPhoneInfo(&st_lock_phone_info);
不规范代码规范代码
2.2代码行
●【规则2-2-1】一行代码只做一件事情,如只定义一个变量,或只写一条语句。
这样的代码容易阅读,并且方便于写注释。
●【规则2-2-2】if、for、while、do等语句自占一行,执行语句不得紧跟其后。
不论执行语句有多少都要加{}。
这样可以防止书写失误。
intwidth,height,depth;//宽度高度深度
intwidth;//宽度
intheight;//高度
intdepth;//深度
X=a+b;y=c+d;z=e+f;
x=a+b;
y=c+d;
z=e+f;
if(width if(width { dosomething(); } for(initialization;condition;update) dosomething(); other(); for(initialization;condition;update) { dosomething(); } //空行 other(); 不规范代码规范代码 2.3代码行内的空格 说明: 空格的目的在于更清晰的代码。 ●【规则2-3-1】关键字之后要留空格。 const、static等关键字之后至少要留一个空格,否则无法辨析关键字;if、for、while、switch等关键字之后应留一个空格再跟左括号‘(’,以突出关键字。 ●【规则2-3-2】函数名之后不要留空格,紧跟左括号‘(’,以与关键字区别。 ●【规则2-3-3】‘(’向后紧跟,‘)’、‘,’、‘;’向前紧跟,紧跟处不留空格。 ●【规则2-3-4】‘,’之后要留空格,如Function(x,y,z)。 如果‘;’不是一行的结束符号,其后要留空格,如for(initialization;condition;update)。 ●【规则2-3-5】赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符,如“=”、“+=”“>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<”,“^”等二元操作符的前后应当加一个空格。 ●【规则2-3-6】一元操作符如“! ”、“~”、“++”、“--”、“&”(地址运算符)等前后不加空格。 ●【规则2-3-7】象“[]”、“.”、“->”这类操作符前后不加空格。 ●【建议2-3-1】对于表达式比较长的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>=b)&&(c<=d)) if((a>=b)&&(c<=d)) if(a>=b&&c<=d) for(i=0;i<10;i++) for(i=0;i<10;i++) for(i=0;i<10;i++) x=a a: b; x=a a: b; i++; int*x=&y; i++; int*x=&y; array[5]=0; a.Function(); b->Function(); array[5]=0; a.Function(); b->Function(); 良好风格不良风格 2.4对齐缩进 ●【规则2-4-1】程序块要采用缩进风格编写。 ●【规则2-4-2】对齐使用TAB键,TAB键宽度设置为4个空格。 说明: 应注意使用不同编辑器时,TAB键设置不同造成的排版不同;应注意某些编辑器在识别、显示TAB键上存在问题;最终排版应以在项目的主代码编辑器(如VC、SourceInsight等)中显示一致统一、整洁清晰为准。 SourceInsight中设置: Options->DoucumentOptions->“TabWidth: 4” ●【规则2-4-3】函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格,case语句下的情况处理语句也要遵从语句缩进要求。 ●【规则2-4-4】程序块的分界符(如‘{’和‘}’)应各独占一行并且位于同一列,同时与引用它们的语句左对齐。 在函数体的开始、类的定义、结构的定义、枚举的定义以及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。 for(...){ ...//programcode } for(...) { ...//programcode } if(...) { ...//programcode } if(...) { ...//programcode } voidexample_fun(void) { ...//programcode } voidexample_fun(void) { ...//programcode } 不规范代码规范代码 ●【规则2-4-5】预处理指令不需要缩进,总是从行首开始。 即使预处理指令位于缩进代码块中,指令也应从行首开始。 //良好风格: 预处理指令均从行首开始 if(lopsided_score) { #ifDISASTER_PENDING//Correct--Startsatbeginningofline DropEverything(); #ifNOTIFY NotifyClient(); #endif #endif BackToNormal(); } //不良风格: 缩进的预处理指令 if(lopsided_score) { #ifDISASTER_PENDING//Wrong! The"#if"shouldbeatbeginningofline DropEverything(); #endif//Wrong! Donotindent"#endif" BackToNormal(); } 2.5长行拆分 ●【规则2-5-1】代码行最大长度宜控制在100至110个字符以内。 代码行不要过长,否则眼睛看不过来,也不便于打印。 ●【规则2-5-2】较长的语句(>110字符)要分成多行书写;长表达式要在低优先级操作符处拆分成新行,操作符放在新行之首(以便突出操作符)。 拆分出的新行要进行适当的缩进,使排版整齐,语句可读。 ●【规则2-5-3】循环、判断等语句中若有较长的表达式或语句,则要进行适应的划分.长表达式要在低优先级操作符处划分新行,操作符放在新行之首。 ●【规则2-5-4】若函数或过程中的参数较长,则要进行适当的划分。 if((very_longer_variable1>=very_longer_variable12) &&(very_longer_variable3<=very_longer_variable14) &&(very_longer_variable5<=very_longer_variable16)) { dosomething(); } virtualCMatrixCMultiplyMatrix(CMatrixleftMatrix, CMatrixrightMatrix); for(very_longer_initialization; very_longer_condition; very_longer_update) { dosomething(); } report_or_not_flag=((taskno &&(n7stat_stat_item_valid(stat_item)) &&(act_task_table[taskno].result_data! =0)); n7stat_str_compare((BYTE*)&stat_object, (BYTE*)&(act_task_table[taskno].stat_object), sizeof(_STAT_OBJECT)); 长行的拆分 第三章注释 3.1通用规则 ●【规则3-1-1】一般情况,需要保证程序有一定的注释。 必须保证关键的函数、流程、类型定义、变量等有相应注释说明。 说明: 注释的原则是有助于对程序的阅读理解,在该加的地方都加了,注释不宜太多也不能太少,注释语言必须准确、易懂、。 ●【规则3-1-2】注释应当准确、易懂,防止注释有二义性。 说明: 错误的注释不但无益反而有害。 ●【规则3-1-3】除非能使用准确的英文表达,则使用中文注释。 ●【规则3-1-4】避免在注释中使用缩写,特别是非常用缩写。 说明: 在使用缩写时或之前,应对缩写进行必要的说明。 ●【规则3-1-5】需要为代码中使用的缩写增加注释,文件引入的新缩写必须在文件头部加以说明。 ●【规则3-1-6】通过对函数或过程、变量、结构等正确的命名以及合理地组织代码的结构,使代码成为自注释的。 说明: 清晰准确的函数、变量等的命名,可增加代码可读性,并减少不必要的注释。 ●【规则3-1-7】注释格式尽量统一。 建议使用//进行注释,多行注释可使用“/*……*/”。 3.2文件注释 ●【规则3-2】源文件(包含.h头文件、.c源文件及各种脚本文件等)头部应进行注释,应列出: 版权说明、文件名、文件目的/功能,作者、创建日期等;如果源文件引入了新的缩写,则必须在文件头部注释说明。 文件注释格式定义如下(可以不局限于该格式中定义的内容,但必须包含该格式中定义的内容): /************************************************************ **Copyright(C)2010-2011,XXXCo.Ltd. **Allrightsreserved. ** **FileName: //文件名称 **Description: //文件描述 **Author: //作者 **Date: //创建时间 **Others: //其它说明 ***********************************************************/ /************************************************************ Abbreviation: //如果文件引入了新的缩写,则必须在此处加以说明 ***********************************************************/ 举例如下: /************************************************************ **Copyright(C)2010-2011,XXXCo.Ltd. **Allrightsreserved. ** **FileName: starlib_nvset.h **Description: NV参数配置源文件 **Author: zc **Date: 2010/4/13 **Others: ***********************************************************/ /************************************************************ Abbreviation: NCM: NetChooseMenu网络选择菜单 VBC: VoiceBroadcast语音播报 ***********************************************************/ 3.3函数注释 ●【规则3-3】函数头部应进行注释,需要列出函数的功能、参数、返回值等。 函数注释格式定义如下(可以不局限于该格式中定义的内容,但必须包含该格式中定义的内容): /****************************************************************/ //Function: //函数名称 //Description: //函数功能描述 //Param: //参数说明,包括参数的作用、取值范围等,格式如下: //param1: 输入输出类型[IN/OUT/INOUT]说明 //param2: 输入输出类型[IN/OUT/INOUT]说明 //… //Return: //函数返回值说明 //Others: //其它说明 //Author: //作者 /****************************************************************/ 举例如下: /****************************************************************/ //Function: StarLib_SetIdleNetIconType //Description: 设置待机界面网络图标 //PARAM: icon: [IN]待机界面网络图标 //Return: 设置成功=STARLIB_TRUE //设置失败=STARLIB_FALSE //Others: //Author: zc /****************************************************************/ 3.4数据注释 ●【规则3-4-1】对于所有有物理含义的变量、常量,如果其命名不是充分自注释的,在声明时都必须加以注释,说明其物理含义。 变量、常量、宏的注释应放在其上方相邻位置或右方。 //activestatistictasknumber #defineMAX_ACT_TASK_NUMBER1000 #defineMAX_ACT_TASK_NUMBER1000//activestatistictasknumber ●【规则3-4-2】数据结构声明(包括结构体、枚举、类等),如果其命名不是充分自注释的,必须加以注释。 对数据结构的注释应放在其上方相邻位置;对结构中每个域的注释放在该域的右方。 //sccpinterfacewithsccpuserprimitivemessagename enumSCCP_USER_PRIMITIVE { N_UNITDATA_IND,//sccpnotifysccpuserunitdatacome N_NOTICE_IND,/*sccpnotifyusertheNo.7networkcannot transmissionthismessage*/ N_UNITDATA_REQ,//sccpuser'sunitdatatransmissionrequest }; ●【规则3-4-3】全局变量必须有注释,包括对其功能、取值、及其他注意事项等的说明。 //标志是否通过锁卡流程;TURE=通过锁卡流程,FALSE=锁卡流程失败 PUBLICBOOLEANg_isLockCardPass=FALSE; 3.5代码注释 ●【规则3-5-1】边写代码边注释,修改代码同时修改相应的注释,以保证注释与代码的一致性。 不再有用的注释要删除! ●【规则3-5-2】如果代码本来就是清楚的,则不必加注释。 i++;//i加1,多余的注释 ●【规则3-5-3】在代码的功能、意图层次上进行注释,提供有用、额外的信息。 //ifreceive_flagisTRUE if(receive_flag) //ifmtpreceiveamessagefromlinks if(receive_flag) 无用注释有用注释 ●【规则3-5-4】注释应与其描述的代码相邻。 对语句块的注释必须放在语句块上方;对单条语句、变量定义的注释可以放在上方或右方(建议放在右方);注释不可放在下方。 //getreplicatesubsystemindexandnetindicator repssn_ind=ssn_data[index].repssn_index; repssn_ni=ssn_data[index].ni; 不良写法一 repssn_ind=ssn_data[index].repssn_index; repssn_ni=ssn_data[index].ni; //getreplicatesubsystemindexandnetindicator 不良写法二 //getreplicatesubsystemindexandnetindicator repssn_ind=ssn_data[index].repssn_index; repssn_ni=ssn_data[index].ni; 良好的写法 ●【规则3-5-5】如果注释放在上方,则将注释与其上面的代码用空行隔开。 //codeonecomments programcodeone //codetwocomments programcodetwo //codeonecomments programcodeone //codetwocomments programcodetwo 过于紧凑良好写法 ●【规则3-5-6】避免在一行代码或表达式的中间插入注释。 说明: 除非必要,不应在代码或表达中间插入注释,否则容易使代码可理解性变差。 ●【规则3-5-7】对于switch语句下的case语句,如果因为特殊情况需要处理完一个case后进入下一个case处理,必须在该case语句处理完、下一个case语句前加上明确的注释。 说明: 这样比较清楚程序编写者的意图,有效防止无故遗漏break语句。 caseCMD_A: ProcessA(); break; caseCMD_B: ProcessB(); //跳转到caseCMD_C caseCMD_C: ProcessC(); break; ●【规则3-5-8】注释与所描述内容进行同样的缩排。 说明: 可使程序排版整齐,并方便注释的阅读与理解。 voidexample_fun(void) { //codeonecomments CodeBlockOne //codetwocomments CodeBlockTwo } voidexample_fun(void) { //codeonecomments CodeBlockOne //codetwocomments CodeBlockTwo } 不好的注释缩排良好的注释缩排 第四章命名 4.1通用命名规则 ●【规则4-1-1
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 开发 代码 标准 语言