C++编程规范Word下载.docx
《C++编程规范Word下载.docx》由会员分享,可在线阅读,更多相关《C++编程规范Word下载.docx(30页珍藏版)》请在冰豆网上搜索。
9.代码内名称和源文件所使用的命名约定;
10.何时使用某些语言结构以及何时应避免某些语言结构。
基本原则
11.清晰、可理解的源代码是影响软件可靠性和可维护性的主要因素。
清晰、可理解的代码可以表示为以下三个简单的基础原理:
⏹最小混淆:
软件的生存期中,源代码的读远比写多,规范、标准更是这样。
理想情况下,源代码读起来应该象英语一样描述了所要做的事,这同时还带来了它执行的好处。
程序本质上是为人编写,而不是为计算机编写的。
阅读代码是一个复杂的脑力过程,它可由统一标准来简化,在本文中还指最小混淆原则。
整个项目中统一样式是软件开发团队在编程标准上达成一致的主要原因,它不应视为一种惩罚或对创造性和生产力的阻碍。
⏹维护的唯一点:
只要可能,设计决策就应在源中只表述一点,它的多数后果应程序化的派生于此点。
不遵守这一原则严重损害了可维护性、可靠性和可理解性。
⏹最小干扰:
避免将源代码与可视干扰(如内容较少或对理解软件目的不起作用的信息)相混合:
12.所表达的精神不过于苛刻;
而对正确安全的使用语言特性提供指导。
优秀软件的关键在于:
⏹了解每一个特性以及它的限制和潜在的危险;
⏹确切了解此特性可安全的使用于哪一个环境中;
⏹做出使用高度可视特性的决定;
⏹在合适的地方小心适度的使用特性。
文件结构
每个C++/C程序通常分为两个文件。
一个文件用于保存程序的声明(declaration),称为头文件。
另一个文件用于保存程序的实现(implementation),称为定义(definition)文件。
C++/C程序的头文件以“.h”为后缀,C程序的定义文件以“.c”为后缀,C++程序的定义文件通常以“.cpp”为后缀(也有一些系统以“.cc”或“.cxx”为后缀)。
版权和版本的声明
版权和版本的声明位于头文件和定义文件的开头,主要内容有:
13.版权信息。
14.文件名称,标识符,摘要。
15.当前版本号,作者/修改者,完成日期。
16.版本历史信息。
/**
*Copyright(c)2004,光庭导航数据(武汉)有限公司
*Allrightsreserved.
*
*文件名称:
filename.h
*摘要:
简要描述本文件的内容
*当前版本:
1.1
*作者:
输入作者(或修改者)名字
*完成日期:
2004年×
月×
日
*取代版本:
1.0
*原作者:
输入原作者(或修改者)名字
2004年月日
**/
【说明】
关于类的版权和版本申明要保持C++工程和RoseUML模型的统一,鉴于在RoseUML模型中编写这些声明比较麻烦导致工作量增加,所以可以在VC中使用“VC助手”工具帮助快速编写该类的版权和版本申明,在VC中编写好申明后要将该C++工程反转到RoseUML模型中,以保持C++工程和RoseUML模型的统一。
使用VC助手的方法:
17.点击助手工具栏的Options按钮
18.点击Completion页面的Edit按钮
19.找到
/**:
/************************************************************************/
/*?
*/
/************************************************************************/
修改为:
*?
2004年月日
**/
使用方法:
在VC中输入"
/**"
等待出现提示,然后回车即出现类注释。
⏹【提示3-1-1】通过上述方法可以在“VC助手”中编辑各种模板以提高编写代码的效率。
头文件的结构
头文件由三部分内容组成:
20.头文件开头处的版权和版本声明。
21.预处理块。
22.函数和类结构声明等。
⏹【规则3-2-1】为了防止头文件被重复引用,应当用ifndef/define/endif结构产生预处理块。
⏹【规则3-2-2】用#include<
filename.h>
格式来引用标准库的头文件(编译器将从标准库目录开始搜索)。
⏹【规则3-2-3】用#include“filename.h”格式来引用非标准库的头文件(编译器将从用户的工作目录开始搜索)。
⏹【规则3-2-4】头文件中只存放“声明”而不存放“定义”
在C++语法中,类的成员函数可以在声明的同时被定义,并且自动成为内联函数。
这虽然会带来书写上的方便,但却造成了风格不一致,弊大于利。
建议将成员函数的定义与声明分开,不论该函数体有多么小。
即使是缺省的构造函数和析构函数也不允许在头文件中定义。
⏹【规则3-2-5】不提倡使用全局变量,尽量不要在头文件中出现象externintvalue这类声明。
如果要保留全局变量,那么全局变量要保存在一个类中。
定义文件的结构
定义文件有三部分内容:
23.定义文件开头处的版权和版本声明。
24.对一些头文件的引用。
25.程序的实现体(包括数据和代码)
头文件的作用
26.通过头文件来调用库功能。
在很多场合,源代码不便(或不准)向用户公布,只要向用户提供头文件和二进制的库即可。
用户只需要按照头文件中的接口声明来调用库功能,而不必关心接口怎么实现的。
编译器会从库中提取相应的代码。
27.头文件能加强类型安全检查。
如果某个接口被实现或被使用时,其方式与头文件中的声明不一致,编译器就会指出错误,这一简单的规则能大大减轻程序员调试、改错的负担。
目录结构
如果一个软件的头文件数目比较多(如超过十个),通常应将头文件和定义文件分别保存于不同的目录,以便于维护。
例如可将头文件保存于include目录,将定义文件保存于source目录(可以是多级目录)。
如果某些头文件是私有的,它不会被用户的程序直接引用,则没有必要公开其“声明”。
为了加强信息隐藏,这些私有的头文件可以和定义文件存放于同一个目录。
程序的版式
版式虽然不会影响程序的功能,但会影响可读性。
程序的版式追求清晰、美观,是程序风格的重要构成因素。
空行
空行起着分隔程序段落的作用。
空行得体(不过多也不过少)将使程序的布局更加清晰。
空行不会浪费内存。
。
⏹【规则4-1-1】在每个类声明之后、每个函数定义结束之后都要加一行空行。
⏹【规则4-1-2】在一个函数体内,逻揖上密切相关的语句之间不能加空行,而在逻辑上有区别的段落之间必须加空行。
例如:
//连接数据库
{
……
}
//从数据库中读取数据
……
代码行
⏹【规则4-2-1】一行代码只做一件事情,如只定义一个变量,或只写一条语句。
这样的代码容易阅读,并且方便于写注释。
⏹【规则4-2-2】if、for、while、do等语句自占一行,执行语句不得紧跟其后。
不论执行语句有多少都要加{}。
这样可以防止书写失误。
⏹【规则4-2-3】函数内定义变量都应放在函数的开始统一进行,以减少出现内存碎片的机会。
⏹【建议4-2-1】尽可能在定义变量的同时初始化该变量(就近原则)
如果变量的引用处和其定义处相隔比较远,变量的初始化很容易被忘记。
如果引用了未被初始化的变量,可能会导致程序错误。
代码行内的空格
⏹【规则4-3-1】关键字之后要留空格。
象const、virtual、inline、case等关键字之后至少要留一个空格,否则无法辨析关键字。
象if、for、while等关键字之后应留一个空格再跟左括号‘(’,以突出关键字。
⏹【规则4-3-2】函数名之后不要留空格,紧跟左括号‘(’,以与关键字区别。
⏹【规则4-3-3】‘(’向后紧跟,‘)’、‘,’、‘;
’向前紧跟,紧跟处不留空格。
⏹【规则4-3-4】‘,’之后要留空格,如Function(x,y,z)。
如果‘;
’不是一行的结束符号,其后要留空格,如for(initialization;
condition;
update)。
⏹【规则4-3-5】赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符,如“=”、“+=”“>
=”、“<
=”、“+”、“*”、“%”、“&
&
”、“||”、“<
<
”,“^”等二元操作符的前后应当加空格。
⏹【规则4-3-6】一元操作符如“!
”、“~”、“++”、“--”、“&
”(地址运算符)等前后应当加空格。
⏹【规则4-3-7】象“[]”、“.”、“->
”这类操作符前后不加空格。
对齐
⏹【规则4-4-1】程序的分界符‘}’应独占一行并且与引用它们的语句左对齐。
‘{’可以另起一行,于‘}’左对齐,也可以放在引用它们的语句后面。
⏹【规则4-4-2】{}之内的代码块在引用语句的右边间隔一个“Tab”处左对齐。
长行拆分
⏹【规则4-5-1】代码行最大长度不能超过80个字符。
⏹【规则4-5-2】长表达式要在低优先级操作符处拆分成新行,操作符放在新行之首(以便突出操作符)。
拆分出的新行要进行适当的缩进,使排版整齐,语句可读。
修饰符的位置
⏹【规则4-6-1】修饰符靠近数据类型和变量名。
int*x;
//x是int类型的指针。
x=100;
//给x赋值
注释
C语言的注释符为“/*…*/”。
C++语言中,程序块的注释常采用“/*…*/”,行注释一般采用“//…”。
注释通常用于:
28.版本、版权声明;
29.函数接口说明;
30.重要的代码行或段落提示。
虽然注释有助于理解代码,但注意不可过多地使用注释。
⏹【规则4-7-1】注释是对代码的“提示”,不是文档。
程序中的注释应言简意赅,不说废话。
注释的花样要少。
⏹【规则4-7-2】如果代码本来就是清楚的,则不必加注释。
⏹【规则4-7-3】边写代码边注释,修改代码同时修改相应的注释,以保证注释与代码的一致性。
不再有用的注释要删除。
⏹【规则4-7-4】注释应当准确、易懂,防止注释有二义性。
⏹【规则4-7-5】尽量避免在注释中使用缩写,特别是不常用缩写。
⏹【规则4-7-6】注释的位置应与被描述的代码相邻,放在代码的上方或右方(对单条语句的注释),不可放在下方。
⏹【规则2-7-8】当代码比较长,特别是有多重嵌套时,