CC编码规范(学习模板)_第1页
CC编码规范(学习模板)_第2页
CC编码规范(学习模板)_第3页
CC编码规范(学习模板)_第4页
CC编码规范(学习模板)_第5页
已阅读5页,还剩12页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

C&C++编码规范

目录1编写目的 12程序版式 12.1基本排版说明 12.1.1空行 12.1.2代码行 12.1.3代码行内的空格 12.1.4缩进对齐 22.1.5长行拆分 22.1.6修饰符 22.1.7类 22.2源文件格式 22.2.1文件头 32.2.2头文件的结构 32.2.3定义文件的结构 42.3注释和说明 42.3.1注释一般风格 52.3.2文件开头注释 52.3.3变量注释 52.3.4函数注释 52.3.5程序块注释 63命名规则 63.1共性规则 63.2宏(#define) 73.3类型定义(#typedef) 73.4变量 83.5结构 83.6函数 83.7常量 83.8类中的常量 94表达式和基本语句 104.1运算符的优先级 104.2复合表达式 104.3 if语句写法 104.4 for语句写法 114.5 while语句写法 114.6 switch语句写法 114.7 goto语句写法 115 函数和过程 125.1命名规则 125.2函数输入 125.3 函数输出 135.4 函数返回值 136 基于性能和优化的其他建议 131编写目的为规范开发过程,在项目组中统一代码风格,提高代码质量,增加后续代码的易读性和可维护性,特编写此文档。2程序版式版式虽然不会影响程序的功能,但会影响可读性。程序的版式追求清晰、美观,是程序风格的重要构成因素。2.1基本排版说明2.1.1空行空行起着分隔程序段落的作用。空行得体(不过多也不过少)将使程序的布更加清晰。空行不会浪费内存,虽然打印含有空行的程序是会多消耗一些纸,但是值得。所以不要舍不得用空行。在每个类声明之后、每个函数定义结束之后都要加空行。在一个函数体内,逻揖上密切相关的语句之间不加空行,其它地方应加空行分隔。2.1.2代码行一行代码只做一件事情,如只定义一个变量,或只写一条语句。这样的代码容易阅读,并且方便于写注释。if、for、while、do等语句自占一行,执行语句不得紧跟其后。不论执行语句有多少都要加{}。这样可以防止书写失误。2.1.3代码行内的空格函数名和关键字紧跟左括号‘(’,之后不要留空格。‘(’向后紧跟,‘)’、‘,’、‘;’向前紧跟,紧跟处不留空格;‘,’之后要留空格,如Function(x,y,z)。如果‘;’不是一行的结束符号,其后要留空格,如for(initialization;condition;update)。赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符,如“=”、“+=”“>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<”,“^”等二元操作符的前后应当加空格。一元操作符如“!”、“~”、“++”、“--”、“&”(地址运算符)等前后不加空格;“[]”、“.”、“->”这类操作符前后不加空格。对于表达式比较长的for语句和if语句,为了紧凑起见可以适当地去掉一些空格,如for(i=0;i<10;i++)和if((a<=b)&&(c<=d))2.1.4缩进对齐程序的分界符‘{’和‘}’应独占一行并且位于同一列,同时与引用它们的语句左对齐;{}之内的代码块在‘{’右边缩进对齐。相邻层次间的语句缩进长度为4个空格。在编辑器允许的情况下,建议将tab键的宽度定义为4个字符宽,而一tab键缩进。2.1.5长行拆分代码行最大长度宜控制在70至80个字符以内。代码行不要过长,否则眼睛看不过来,也不便于打印。另外,多于80字符的行不能被一些终端或工具很好的处理。长表达式的断行原则:要在逗号后断行;要在操作符前断行;要在低优先级操作符处拆分成新行;在新行续表达式时,要和上一行的同一级对齐。如果上面的规则导致代码混乱或者把代码压出了右边界,那么只缩进8个空格即可。缩进的原则是使排版整齐,语句可读。if、for、while语句断行时通常应当用8个空格,因为常规缩进(4个空格)难以看清语句体。2.1.6修饰符应当将修饰符*和&紧靠变量名。2.1.7类显式说明private限定符。将public类型的函数写在前面,而将private类型的数据写在后面,重点关注的是类应该提供什么样的接口(或服务)。2.2源文件格式每个C++/C程序通常分为两个文件。一个文件用于保存程序的声明(declaration),称为头文件。另一个文件用于保存程序的实现(implementation),称为定义(definition)文件。C++/C程序的头文件以“.h”为后缀(或以.hxx、.hpp为后缀),C程序的定义文件以“.c”为后缀,C++程序的定义文件通常以“.cpp”为后缀(也有一些系统以“.cc”或“.cxx”为后缀)。一个文件通常由多节(sections)组成,节与节之间应以空行隔开,且每节都应有相应的注释来标识。尽量避免一个文件超过2000行。文件命名应尽可能反映文件实现的功能。2.2.1文件头文件头主要是版权和版本的声明,一般存在于在头文件和定义文件的开头,主要内容有:版权信息。文件名称,标识符,摘要。当前版本号,作者/修改者,完成日期。版本历史信息。举例如下:/*/**Copyright(c)2010,××××××××有限公司*Allrightsreserved.**文件名称:file.h*摘要:简要描述本文件的内容**当前版本:1.1*作者:输入作者(或修改者)名字*完成日期:2010年7月20日**[取代版本:1.0*原作者:输入原作者(或修改者)名字*完成日期:2009年7月20日]**修订记录:*修订日期修订人修订内容*2010年7月20日程序员姓名修改文件说明**/2.2.2头文件的结构头文件由三部分内容组成:头文件开头处的版权和版本声明。预处理块。函数和类结构、接口声明等。为了防止头文件被重复引用,应当用ifndef/define/endif结构产生预处理块。宏定义的变量名以一个(或者两个)下划线打头、并以一个(或者两个)下划线结尾,中间将头文件名的“.”替换为一个下划线组成。用#include<filename.h>格式来引用标准库的头文件(编译器将从标准库目录开始搜索);用#include“filename.h”格式来引用非标准库的头文件(编译器将从用户的工作目录开始搜索)。头文件中只存放“声明”而不存放“定义”。在C++语法中,类的成员函数可以在声明的同时被定义,并且自动成为内联函数。这虽然会带来书写上的方便,但却造成了风格不一致,弊大于利。建议将成员函数的定义与声明分开,不论该函数体有多么小。不提倡使用全变量,尽量不要在头文件中出现象externintvalue这类声明。2.2.3定义文件的结构定义文件有三部分内容定义文件开头处的版权和版本声明。对一些头文件的引用。程序的实现体(包括数据和代码)。2.3注释和说明程序通常有两种类型的注释:实现注释和文档注释。实现注释以/*...*/和//标志(仅对C++有效)。文档注释以/*...*/标志,通过在程序中加文档注释,便于通过各类工具将文档注释从程序中提取出来形成HTML文档,作为程序接口描述文档。实现注释主要用来对代码的具体实现进行描述;而文档注释用来从实现透明的角度描述代码的规格,以便开发者了解和使用该代码时无须把源代码放在手边或详细研读实现代码。注释应对代码进行概括总结并提供从代码本身无法直接看出的附加信息。注释中应只包括与阅读、理解程序相关的信息。例如,如何生成相应的包或它本身放在什么目录下等信息不应当包括在注释中。在写注释时,要说明有价值的或无法明显看出的信息,尽量避免重复那些呈现在代码中的明显信息。2.3.1注释一般风格修改代码中要加入修改内容、修改人、修改时间注释的位置应与被描述的代码相邻,可以放在代码的上方或右方,不可放在下方注释是对代码的“提示”,而不是文档。程序中的注释不可喧宾夺主,注释太多了会让人眼花缭乱。注释的花样要少。边写代码边注释,注释量不少于20%;修改代码同时修改相应的注释,以保证注释与代码的一致性。不再有用的注释要删除。注释应当准确、易懂,防止注释有二义性。尽量避免在注释中使用缩写,特别是不常用缩写。2.3.2文件开头注释文件开头注释即版本和版权声明,见上。2.3.3变量注释对于所有有物理含义的变量、常量,如果其命名不是充分自注释的,在声明时都必须加以注释,说明其物理含义如果代码本来就是清楚的,则不必加注释。否则多此一举,令人厌烦。如:i++; //i加1,多余的注释2.3.4函数注释每个函数定义的时候都必须有对应的注释,包含但不限于以下内容:功能描述输入参数输出参数返回值函数注释格式如下:/*/***功能描述:*输入参数:*输出参数:*返回值:*/函数的注释内容可以扩充,但在一个项目中格式应该统一。2.3.5程序块注释程序块的注释采用/*…*/。当代码比较长,特别是有多重嵌套(if、for等)时,应当在一些段落的结束处加注释。3命名规则命名应具有描述性,即命名可描述被描述对象的功能、作用等。命名应使用标准的英文单词(包括缩写)或完整的汉语拼音。使用英文单词时应注意使用较常用且含义较明确的词,而不要使用含义不清或容易引起混淆的词。某些词因用途较广而导致含义不清,如treat、data、system等。某些词因在业内已有特定含义而导致易产生误解,如windows、socket等。使用以上类型的词时应特别注意,应保证该词在项目中有明确的含义。不要使用较冷僻的词。如该单词属于与某行业相关的专业术语,应保证其在项目中有明确定义后再使用,或直接使用汉语拼音。除已被公认的缩写方式(如sys、num等)外,不要使用缩写。对于项目中特定的较常用的词,如需缩写,应明确定义。如果无法找到相应的英文单词(如纯粹的中文名称)或相应的英文单词较冷僻,应使用汉语拼音。使用汉语拼音时应注意完整而准确,不要缩写,不要因方言的影响而使用错误的拼音。字符的大小写及下划线’_’的使用:对于不同类型的命名对象,各英文单词(或汉语拼音单字)的大小写方式可分为如下几种:全大写、全小写、英文单词(或汉语拼音单字)的首字母大写,下划线应加在英文单词(或汉语拼音单词之间)。3.1共性规则本节论述的共性规则是被大多数程序员采纳的,我们应当在遵循这些共性规则的前提下,再扩充特定的规则。标识符应当直观且可以拼读,可望文知意,不必进行“解码”。标识符最好采用英文单词或其组合,便于记忆和阅读,切忌直接使用汉语拼音来命名。标识符的长度应当符合“min-length&&max-information”原则。程序中不要出现仅靠大小写区分的相似的标识符。程序中不要出现标识符完全相同的部变量和全变量,尽管两者的作用域不同而不会发生语法错误,但会使人误解。变量的名字应当使用“名词”或者“形容词+名词”。全函数的名字应当使用“动词”或者“动词+名词”(动宾词组)。类的成员函数应当只使用“动词”,被省略掉的名词就是对象本身。用正确的反义词组命名具有互斥意义的变量或相反动作的函数等。尽量避免名字中出现数字编号,如Value1,Value2等,除非逻辑上的确需要编号。这是为了防止程序员偷懒,不肯为命名动脑筋而导致产生无意义的名字(因为用数字编号最省事)。3.2宏(#define)对于常数或表达式,宏名称应使用名词(或名词性词组)描述该常数的含义或表达式所得到的数据内容,各单词均应大写,并以下划线分隔。如:MAX_CHAR_NUM。对于特定处理,宏名称应使用动词(或动宾词组)描述所作的处理。各单词均大写,但单词间不加下划线。如:ADDXY。用宏定义表达式时,要使用完备的括号。将宏所定义的多条表达式放在大括号中。使用宏时,不允许参数发生变化。3.3类型定义(#typedef)使用typedef定义结构,struct后使用“_”命名,结构类型不带下划线。typedeftypedef struct_TIME_DATA{ charisTime[DATE_STD_LEN+1]; /*时间*/ charisYear[DATE_YEAR_LEN+1]; /*年*/ charisMon[DATE_MON_LEN+1]; /*月*/ charisDay[DATE_DAY_LEN+1]; /*日*/ charisHour[DATE_HOUR_LEN+1]; /*时*/ charisMin[DATE_MIN_LEN+1]; /*分*/ charisSec[DATE_SEC_LEN+1]; /*秒*/}TIME_DATA;3.4变量变量名应以一个或几个小写字符为前缀,描述该变量的类型,一般为相应类型的首字母或者前两个字母,如int类型用i,char类型用ch等,后跟一个或几个单词描述该变量的作用,各单词的首字母大写。如:iItemNum。对于全变量,可在变量名前加上‘g_’,如:g_iItemNum。静态变量加前缀s_(表示static)。应当将修饰符*和&紧靠变量名类的数据成员加前缀m_(表示member),这样可以避免数据成员与成员函数的参数同名。3.5结构结构名以tag为前缀,后跟名词(或名词性词组)描述该结构所描述的对象。结构中定义的各变量应描述该对象的某个属性,其命名规则遵循变量的命名规则。3.6函数类名和函数名用大写字母开头的单词组合而成。全函数名应以动词(或动宾词组)描述该函数的功能,类的成员函数应当只使用动词。用正确的反义词组命名具有互斥意义的变量或相反动作的函数等函数的参数名遵循变量命名规则。函数的声明采用ANSI的新标准,即参数声明在()内。函数名长度通常不超过50字符。3.7常量尽量使用含义直观的常量来表示那些将在程序中多次出现的数字或字符串需要对外公开的常量放在头文件中,不需要对外公开的常量放在定义文件的头部。为便于管理,可以把不同模块的常量集中存放在一个公共的头文件中。如果某一常量与其它常量密切相关,应在定义中包含这种关系,而不应给出一些孤立的值在C++程序中只使用const常量而不使用宏常量,即const常量完全取代宏常量。注:C++语言也可以用#define来定义常量。但是使用const比使用宏常量有更多的优点。1)const常量有数据类型,而宏常量没有数据类型。编译器可以对前者进行类型安全检查。而对后者只进行字符替换,没有类型安全检查,并且在字符替换可能会产生意料不到的错误(边际效应)。2)有些集成化的调试工具可以对const常量进行调试,但是不能对宏常量进行调试。3.8类中的常量有时我们希望某些常量只在类中有效。由于#define定义的宏常量是全的,不能达到目的,于是想当然地觉得应该用const修饰数据成员来实现。const数据成员的确是存在的,但其含义却不是我们所期望的。const数据成员只在某个对象生存期内是常量,而对于整个类而言却是可变的,因为类可以创建多个对象,不同的对象其const数据成员的值可以不同。不能在类声明中初始化const数据成员。以下用法是错误的,因为类的对象未被创建时,编译器不知道SIZE的值是什么。 classA {… constintSIZE=100; //错误,企图在类声明中初始化const数据成员 intarray[SIZE]; //错误,未知的SIZE };const数据成员的初始化只能在类构造函数的初始化表中进行,例如 classA {… A(intsize); //构造函数 constintSIZE; }; A::A(intsize):SIZE(size) //构造函数的初始化表 { … } Aa(100); //对象a的SIZE值为100 Ab(200); //对象b的SIZE值为200怎样才能建立在整个类中都恒定的常量呢?别指望const数据成员了,应该用类中的枚举常量来实现。例如 classA {… enum{SIZE1=100,SIZE2=200};//枚举常量 intarray1[SIZE1]; intarray2[SIZE2]; };枚举常量不会占用对象的存储空间,它们在编译时被全部求值。枚举常量的缺点是:它的隐含数据类型是整数,其最大值有限,且不能表示浮点数(如PI=3.14159)。4表达式和基本语句4.1运算符的优先级如果代码行中的运算符比较多,用括号确定表达式的操作顺序,避免使用默认的优先级。4.2复合表达式不要编写太复杂的复合表达式不要有多用途的复合表达式不要把程序中的复合表达式与“真正的数学表达式”混淆,例如:if(a<b<c)并不表示if((a<b)&&(b<c)),而是成了令人费解的if((a<b)<c)if语句写法常量和变量做等于比较时,要求常量在前,变量在后,如if(2000==year)。不可将布尔变量直接与TRUE、FALSE或者1、0进行比较。应当将整型变量用“==”或“!=”直接与0比较,不可模仿布尔变量的风格而写成if(value)或if(!value)。不可将浮点变量用“==”或“!=”与任何数字比较,应该设法转化成“>=”或“<=”形式,如if((x>=-EPSINON)&&(x<=EPSINON)),其中EPSINON是允许的误差(即精度)。应当将指针变量用“==”或“!=”与NULL比较。if内无论语句多少都要使用一组{},程序的分界符‘{’和‘}’应独占一行并且位于同一列,同时与引用它们的语句左对齐。for语句写法循环内无论语句多少都要使用一组{}。程序的分界符‘{’和‘}’应独占一行并且位于同一列,同时与引用它们的语句左对齐;嵌套的{},则使用缩进对齐。不可在for循环体内修改循环变量,防止for循环失去控制。建议for语句的循环控制变量的取值采用“半开半闭区间”写法。while语句写法在多重循环中,如果有可能,应当将最长的循环放在最内层,最短的循环放在最外层,以减少CPU跨切循环层的次数。如果循环体内存在逻辑判断,并且循环次数很大,宜将逻辑判断移到循环体的外面。合理使用空格。switch语句写法每个case语句的结尾不要忘了加break,否则将导致多个分支重叠(除非有意使多个分支重叠)。不要忘记最后那个default分支。即使程序真的不需要default处理,也应该保留语句 default:break;这样做并非多此一举,而是为了防止别人误以为你忘了default处理。goto语句写法自从提倡结构化设计以来,goto就成了有争议的语句。首先,由于goto语句可以灵活跳转,如果不加限制,它的确会破坏结构化设计风格。其次,goto语句经常带来错误或隐患。它可能跳过了某些对象的构造、变量的初始化、重要的计算等语句,例如:g

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论