没有合适的资源?快使用搜索试试~ 我知道了~
C++编程规范.pdf
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 46 浏览量
2023-09-01
20:13:49
上传
评论 1
收藏 1.24MB PDF 举报
温馨提示
《C++编程规范》是一份旨在提升代码质量、可维护性和开发效率的规范文档,它对C++编程的各个方面提出了明确的要求和指导原则。这份规范适用于所有基于C++语言进行开发的项目,无论是在何种平台上。 规范的核心目标是增强代码的健壮性、可读性和可维护性,同时确保新加入的开发者能够快速适应项目环境,并支持资源的复用。它包含了项目代码的组织方式、编程风格、源代码注释和命名约定,以及何时使用或避免特定的C++语言结构。 基本原则强调了代码清晰性的重要性,认为可理解的代码是软件可靠性和可维护性的关键。最小混淆原则指出,代码应该易于阅读,像英语一样描述其功能。维护的唯一性原则提倡设计决策应在源代码中集中表达,避免分散,以提高可维护性。最小干扰原则则提醒开发者避免在源代码中混入不必要的干扰信息。 文件结构部分,C++/C程序通常分为声明(header)和实现(definition)两个文件。头文件以".h"为后缀,定义文件以".cpp"为后缀,有时也可能是".CC"或".cxx"。每个文件开头应包含版权和版本声明,包括版权信息、文件名、版本号、作者和日期,以保持代码库的管理和追踪。 此外,规范还提到了类的版权和版本声明,建议在C++工程和Rose UML模型之间保持一致性。在Visual Studio(VC)中,可以使用“VC助手”工具来快速生成这些声明,然后在工程反转到Rose UML模型时保持同步。 遵循这份规范,开发者可以写出更加规范、易于理解和维护的C++代码,提高团队协作效率,降低软件开发的风险。同时,通过统一的编码标准,也能减少由于个人习惯差异带来的问题,促进项目的长期稳定发展。
资源推荐
资源详情
资源评论
C++
编程规范
1
简介
为规范项目中以
C++
为基础语言的代码风格,提到代码的健壮性、可维护性,提高开发效率, 特制定本规范。
本规范具有法律效力,除特别说明,或者项目组得到职权部门书面核准,本规范必须执行。
1.1
目的
颁布本规范的目的是:
1.
增加代码的健壮性、可读性、易维护性;减少有经验和无经验开发人员编程所需的脑力 工作;
2.
在项目范围内统一代码风格;
3.
通过人为以及自动的方式对最终软件应用质量标准;
4.
使新的开发人员快速适应项目环境;
5.
支持项目资源的复用:允许开发人员从一个项目区域(或子项目团队)移动到另一个, 而不需要重新适应新
的子项目团队的氛围。
1.2
适用范围
本规范适用于公司所有以
C++
语言为基础的平台下开发的项目。
1.3
概述
本规范包括内容:
1.
如何组织项目代码;
2.
编程风格(如何编写实际的源代码) ;
3.
如何记录源代码;
4.
代码内名称和源文件所使用的命名约定;
5.
何时使用某些语言结构以及何时应避免某些语言结构。
2
基本原则
1.
清晰、可理解的源代码是影响软件可靠性和可维护性的主要因素。清晰、可理解的代码 可以表示为以下三个
简单的基础原理: 最小混淆:软件的生存期中,源代码的读远比写多,规范、标准更是这样。理想情况下,
源代码读起来应该象英语一样描述了所要做的事,这同时还带来了它执行的好处。程序本 质上是为人编写,
而不是为计算机编写的。阅读代码是一个复杂的脑力过程,它可由统一 标准来简化,在本文中还指最小混淆
原则。整个项目中统一样式是软件开发团队在编程标 准上达成一致的主要原因,它不应视为一种惩罚或对创
造性和生产力的阻碍。 维护的唯一点:只要可能,设计决策就应在源中只表述一点,它的多数后果应程序化
的派 生于此点。不遵守这一原则严重损害了可维护性、可靠性和可理解性。
最小干扰:避免将源代码与可视干扰(如内容较少或对理解软件目的不起作用的信息)相 混合:
2.
所表达的精神不过于苛刻;而对正确安全的使用语言特性提供指导。优秀软件的关键在
于:
了解每一个特性以及它的限制和潜在的危险; 确切了解此特性可安全的使用于哪一个环境中; 做出使用高
度可视特性的决定; 在合适的地方小心适度的使用特性。
3
文件结构
每个
C++/C
程序通常分为两个文件。一个文件用于保存程序的声明(
declaration
),称为头文 件。另一个文件
用于保存程序的实现(
implementation
),称为定义(
definition
)文件。
C++/C
程序的头文件以“
.h
”为后缀,
C
程序的定义文件以“
.c
”为后缀,
C++
程序的定义文 件通常以
“
.cpp
”为后缀(也有一些系统以“
.CC
”或“
.cxx
”为后缀)。
3.1
版权和版本的声明
版权和版本的声明位于头文件和定义文件的开头,主要内容有:
1.
2.
3.
4.
/**
版权信息。
文件名称,标识符,摘要。 当前版本号,作者
/
修改者,完成日期。 版本历史信息。
* Copyright (c) 2004
,光庭导航数据(武汉)有限公司
* All rights reserved.
*
*
文件名称:
filename.h
*
摘要:简要描述本文件的内容
*
*
当前版本:
1.1
*
作者:输入作者(或修改者)名字
*
完成日期:
2004
年
X
月
X
日
*
*
取代版本:
1.0
*
原作者:输入原作者(或修改者)名字
*
完成日期:
2004
年 月 日
**/
【说明】
关于类的版权和版本申明要保持 C + +工程和 Rose UML 模型的统一,鉴于在 Rose UML 模型中编写这些声明比较 麻烦导
致工作量增加,所以可以在 VC 中使用“VC 助手”工具帮助快速编写该类的版权和版本申明,在 VC 中编写 好申明后要将
该 C + +工程反转到 Rose UML 模型中,以保持 C + +工程和 Rose UML 模型的统一。
使用
VC
助手的方法:
1.
点击助手工具栏的
Options
按钮
2.
点击
Completion
页面的
Edit
按钮
3.
找到
/**: /************************************************************************/ /* ? */
/************************************************************************/
修改为:
/**:
/**
* Copyright (c) 2004
,光庭导航数据(武汉)有限公司
* All rights reserved.
* o
文件名称:
filename.h
摘要:简要描述本文件的内容 当前版本:
1.1
作者:输入作者(或修改者)名字 完成日
期:
2004
年月日
取代版本:
1.0
原作者:输入原作者(或修改者)名字 完成日期:
2004
年月日
**/
使用方法:在
VC
中输入 等待出现提示,然后回车即出现类注释。
【提示
3-1-1
】通过上述方法可以在“
VC
助手”中编辑各种模板以提高编写代码的效率。
3.2
头文件的结构
头文件由三部分内容组成:
1.
头文件开头处的版权和版本声明。
2.
预处理块。
3.
函数和类结构声明等。
【规则
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
】不提倡使用全局变量,尽量不要在头文件中出现象
extern int value
这类声
明。如果要保留全局变量,那么全局变量要保存在一个类中。
3.3
定义文件的结构
定义文件有三部分内容:
1.
定义文件开头处的版权和版本声明。
2.
对一些头文件的引用。
3.
程序的实现体(包括数据和代码)
3.4
头文件的作用
1.
通过头文件来调用库功能。在很多场合,源代码不便(或不准)向用户公布,只要向用 户提供头文件和二进制
的库即可。用户只需要按照头文件中的接口声明来调用库功能, 而不必关心接口怎么实现的。编译器会从库
中提取相应的代码。
2.
头文件能加强类型安全检查。如果某个接口被实现或被使用时,其方式与头文件中的声 明不一致, 编译器就
会指出错误, 这一简单的规则能大大减轻程序员调试、 改错的负担。
3.5
目录结构
如果一个软件的头文件数目比较多 (如超过十个) ,通常应将头文件和定义文件分别保存于不同 的目录,以便
于维护。
例如可将头文件保存于
include
目录,将定义文件保存于
source
目录(可以是多级目录) 。
如果某些头文件是私有的, 它不会被用户的程序直接引用, 则没有必要公开其 “声明”。为了加 强信息隐藏,
这些私有的头文件可以和定义文件存放于同一个目录。
4
程序的版式
版式虽然不会影响程序的功能,但会影响可读性。程序的版式追求清晰、美观,是程序风格的 重要构成因素。
4.1
空行
空行起着分隔程序段落的作用。空行得体(不过多也不过少)将使程序的布局更加清晰。空行 不会浪费内存。 。
【规则
4-1-1
】在每个类声明之后、每个函数定义结束之后都要加一行空行。
【规则
4-1-2
】在一个函数体内,逻揖上密切相关的语句之间不能加空行,而在逻辑上有 区别的段落之间
必须加空行。例如:
//
连接数据库
{
}
//
从数据库中读取数据
{
4.2
代码行
【规则
4-2-1
】一行代码只做一件事情,如只定义一个变量,或只写一条语句。这样的代 码容易阅读,并
且方便于写注释。
【规则
4-2-2
】
if
、
for
、
while
、
do
等语句自占一行,执行语句不得紧跟其后。不论执行语 句有多少
都要加
{}
。这样可以防止书写失误。
【规则
4-2-3
】函数内定义变量都应放在函数的开始统一进行,以减少出现内存碎片的机 会。
【建议
4-2-1
】尽可能在定义变量的同时初始化该变量(就近原则) 如果变量的引用处和其定义处相隔比
较远,变量的初始化很容易被忘记。如果引用了未被初始 化的变量,可能会导致程序错误。
4.3
代码行内的空格
【规则
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
】赋值操作符、 比较操作符、 算术操作符、 逻辑操作符、 位域操作符, 如“
=
”、
“
+=
” “
>=
”、“
<=
”、“
+
”、“
*
”、“
%
”、“
&&
”、“
||
”、“
<<
”
,
“
A
” 等二元操作符的前后
应当加空格。
剩余24页未读,继续阅读
资源评论
hhappy0123456789
- 粉丝: 72
- 资源: 5万+
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功