没有合适的资源?快使用搜索试试~ 我知道了~
google_c++编程风格(高清版).pdf
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 137 浏览量
2021-11-12
12:39:12
上传
评论
收藏 207KB PDF 举报
温馨提示
试读
50页
google_c++编程风格(高清版).pdf
资源详情
资源评论
资源推荐
Google C++ 编程风格指南
edisonpeng 整理
2009/3/25
Preface
背景 .................................................................................................................................................. 3
头文件 .............................................................................................................................................. 4
作用域 .............................................................................................................................................. 8
C++ 类 ............................................................................................................................................ 13
智能指针和其他 C++ 特性 ........................................................................................................... 20
命名约定 ......................................................................................................................................... 32
代码注释 ......................................................................................................................................... 38
格式 ................................................................................................................................................ 44
规则之例外 ..................................................................................................................................... 57
背景
Google 的项目大多使用 C++ 开发。每一个 C++ 程序员也都知道, C++ 具有很多强大的语言特性,但这
种强大不可避免的导致它的复杂,而复杂性会使得代码更容易出现 bug 、难于阅读和维护。
本指南的目的是通过详细阐述如何进行 C++ 编码来规避其复杂性,使得代码在有效使用 C++ 语言特性的
同时还易于管理。
使代码易于管理的方法之一是增强代码一致性,让别人可以读懂你的代码是很重要的,保持统一编程风格
意味着可以轻松根据“模式匹配”规则推断各种符号的含义。创建通用的、必需的习惯用语和模式可以使
代码更加容易理解, 在某些情况下改变一些编程风格可能会是好的选择, 但我们还是应该遵循一致性原则,
尽量不这样去做。
本指南的另一个观点是 C++ 特性的臃肿。 C++ 是一门包含大量高级特性的巨型语言, 某些情况下, 我们会
限制甚至禁止使用某些特性使代码简化,避免可能导致的各种问题,指南中列举了这类特性,并解释说为
什么这些特性是被限制使用的。
注意:本指南并非 C++ 教程,我们假定读者已经对 C++ 非常熟悉。
头文件
通常,每一个 .cc 文件( C++ 的源文件)都有一个对应的 .h 文件(头文件) ,也有一些例外,如单元测试代
码和只包含 main() 的 .cc 文件。
正确使用头文件可令代码在可读性、文件大小和性能上大为改观。
下面的规则将引导你规避使用头文件时的各种麻烦。
1. #define 保护
所 有 头 文 件 都 应 该 使 用 #define 防 止 头 文 件 被 多 重 包 含 ( multiple inclusion ), 命 名 格 式 为 :
<PROJECT>_<PATH>_<FILE>_H_
为保证唯一性,头文件的命名应基于其所在项目源代码树的全路径。例如,项目 foo 中的头文件
foo/src/bar/baz.h 按如下方式保护:
#ifndef FOO_BAR_BAZ_H_
#define FOO_BAR_BAZ_H_
...
#endif // FOO_BAR_BAZ_H_
2. 头文件依赖
使用前置声明( forward declarations )尽量减少 .h 文件中 #include 的数量。
当一个头文件被包含的同时也引入了一项新的依赖( dependency ),只要该头文件被修改,代码就要重新
编译。如果你的头文件包含了其他头文件,这些头文件的任何改变也将导致那些包含了你的头文件的代码
重新编译。因此,我们应该尽量少的包含头文件,尤其是那些包含在其他头文件中的。
使用前置声明可以显著减少需要包含的头文件数量。举例说明:头文件中用到类 File ,但不需要访问 File
的声明,则头文件中只需前置声明 class File; 无需 #include "file/base/file.h" 。
在头文件如何做到使用类 Foo 而无需访问类的定义?
1) 将数据成员类型声明为 Foo * 或 Foo & ;
2) 参数、返回值类型为 Foo 的函数只是声明(但不定义实现) ;
3) 静态数据成员的类型可以被声明为 Foo ,因为静态数据成员的定义在类定义之外。
另一方面,如果你的类是 Foo 的子类,或者含有类型为 Foo 的非静态数据成员,则必须为之包含头文件。
有时,使用指针成员 (pointer members ,如果是 scoped_ptr 更好)替代对象成员 (object members )
的确更有意义。然而,这样的做法会降低代码可读性及执行效率。如果仅仅为了少包含头文件,还是不要
这样替代的好。
当然, .cc 文件无论如何都需要所使用类的定义部分,自然也就会包含若干头文件。
注:能依赖声明的就不要依赖定义。
3. 内联函数
只有当函数只有 10 行甚至更少时才会将其定义为内联函数( inline function )。
定义( Definition ):当函数被声明为内联函数之后,编译器可能会将其内联展开,无需按通常的函数调用
机制调用内联函数。
优点:当函数体比较小的时候, 内联该函数可以令目标代码更加高效。 对于存取函数 (accessor 、mutator )
以及其他一些比较短的关键执行函数。
缺点:滥用内联将导致程序变慢,内联有可能是目标代码量或增或减,这取决于被内联的函数的大小。内
联较短小的存取函数通常会减少代码量,但内联一个很大的函数(注:如果编译器允许的话)将显著增加
代码量。在现代处理器上,由于更好的利用指令缓存( instruction cache ),小巧的代码往往执行更快。
结论:一个比较得当的处理规则是,不要内联超过 10 行的函数。对于析构函数应慎重对待,析构函数往
往比其表面看起来要长,因为有一些隐式成员和基类析构函数(如果有的话)被调用!
另一有用的处理规则: 内联那些包含循环或 switch 语句的函数是得不偿失的, 除非在大多数情况下,这些
循环或 switch 语句从不执行。
重要的是,虚函数和递归函数即使被声明为内联的也不一定就是内联函数。通常,递归函数不应该被声明
为内联的(译者注:递归调用堆栈的展开并不像循环那么简单,比如递归层数在编译时可能是未知的,大
多数编译器都不支持内联递归函数) 。析构函数内联的主要原因是其定义在类的定义中, 为了方便抑或是对
其行为给出文档。
4. -inl.h 文件
复杂的内联函数的定义,应放在后缀名为 -inl.h 的头文件中。
在头文件中给出内联函数的定义, 可令编译器将其在调用处内联展开。 然而,实现代码应完全放到 .cc 文件
中,我们不希望 .h 文件中出现太多实现代码,除非这样做在可读性和效率上有明显优势。
如果内联函数的定义比较短小、逻辑比较简单,其实现代码可以放在 .h 文件中。例如,存取函数的实现理
所当然都放在类定义中。出于实现和调用的方便,较复杂的内联函数也可以放到 .h 文件中,如果你觉得这
样会使头文件显得笨重,还可以将其分离到单独的 -inl.h 中。这样即把实现和类定义分离开来,当需要时
包含实现所在的 -inl.h 即可。
-inl.h 文件还可用于函数模板的定义,从而使得模板定义可读性增强。
剩余49页未读,继续阅读
BlueWatergg
- 粉丝: 3
- 资源: 11万+
下载权益
C知道特权
VIP文章
课程特权
开通VIP
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0