Google C++编码规范_谷歌编码规范cpp

一、 头文件

  通常每一个.cpp文件都有一个与之对应的.h文件。不过也有一些例外。比如单元测试代码和只包含main()函数的.cpp文件。
正确使用头文件可令代码在可读性、文件大小和性能上大为改观。下面的规则将引导你规避使用头文件时的各种陷阱。

1.1 Self-containned头文件

头文件应该能够自给自足（self-contained,也就是可以作为第一个头文件被引入）以.h结尾。至于用来插入文本的文件，说到底它们并不是头文件，所以应以.inc结尾。不允许分离出-inl.h头文件的做法
1

  不过有一个例外，即一个文件并不是self-contained的，而是作为文本插入到代码某处。或者，文件内容实际上是其它头文件的特定平台（platform-specific）扩展部分。这些文件就要用.inc文件扩展名。
  如果.h文件声明了一个模板或内联函数，同时也在该文件加以定义。凡是有用到这些的.cc文件，就得统统包含该头文件，否则程序可能会在构建中链接失败。不要把这些定义放到分离的-inl.h文件里。
  有个例外：如果某函数模板为所有相关模板参数显式实例化，或本身就是某类的一个私有成员，那么它就只能定义在实例化该模板的.cc文件里。

1.2 #define 保护

所有头文件都应该使用#define来防止头文件被多重包含, 命名格式当是:
<PROJECT>_<PATH>_<FILE>_H_

1
2
3

  为保证唯一性, 头文件的命名应该基于所在项目源代码树的全路径.例如,项目foo中的头文件foo/src/bar/baz.h可按如下方式保护：

#ifndef FOO_BAR_BAZ_H_
#define FOO_BAR_BAZ_H_
...
#endif // FOO_BAR_BAZ_H_
1
2
3
4

1.3 前置申明

尽可能地避免使用前置声明。使用#include包含需要的头文件即可
1

定义
  所谓「前置声明」是类、函数和模板的纯粹声明，没伴随着其定义.
优点

• 前置声明能够节省编译时间，多余的#include会迫使编译器展开更多的文件，处理更多的输入
• 前置声明能够节省不必要的重新编译的时间。#include代码因为头文件中无关的改动而被重新编译多次。

缺点

• 前置声明隐藏了依赖关系，头文件改动时，用户的代码会跳过必要的重新编译过程。
• 前置声明可能会被库的后续更改所破坏。前置声明函数或模板有时会妨碍头文件开发者变动其 API.。例如扩大形参类型，加个自带默认参数的模板形参等等。
• 前置声明来自命名空间 std::的symbol时，其行为未定义
• 很难判断什么时候该用前置声明，什么时候该用#include。极端情况下，用前置声明代替includes甚至都会暗暗地改变代码的含义：

#ifndef FOO_BAR_BAZ_H_
#define FOO_BAR_BAZ_H_
...
#endif // FOO_BAR_BAZ_H_

// b.h:
struct B {}; struct D : B {}

// good_user.cc:
#include "b.h" void f(B*); void f(void*);
void test(D* x) { f(x); } // calls f(B*)
1
2
3
4
5
6
7
8
9
10
11

  如果#include被B和D的前置声明替代，test()就会调用f(void*)。

• 前置声明了不少来自头文件的symbol时，就会比单单一行的include冗长
• 仅仅为了能前置声明而重构代码（比如用指针成员代替对象成员）会使代码变得更慢更复杂。

结论

• 尽量避免前置声明那些定义在其他项目中的实体
• 函数：总是使用#include
• 类模板：优先使用#include

  至于什么时候包含头文件，参见 1.5 #include 的路径及顺序

1.4 内联函数

只有当函数只有10行甚至更少时才将其定义为内联函数
1

定义
  当函数被声明为内联函数之后, 编译器会将其内联展开, 而不是按通常的函数调用机制进行调用。
优点
  只要内联的函数体较小, 内联该函数可以令目标代码更加高效. 对于存取函数以及其它函数体比较短, 性能关键的函数, 鼓励使用内联。
缺点
  滥用内联将导致程序变得更慢. 内联可能使目标代码量或增或减, 这取决于内联函数的大小. 内联非常短小的存取函数通常会减少代码大小, 但内联一个相当大的函数将戏剧性的增加代码大小. 现代处理器由于更好的利用了指令缓存, 小巧的代码往往执行更快。
结论

• 一个较为合理的经验准则是, 不要内联超过 10 行的函数. 谨慎对待析构函数, 析构函数往往比其表面看起来要更长, 因为有隐含的成员和基类析构函数被调用!
• 另一个实用的经验准则: 内联那些包含循环或switch语句的函数常常是得不偿失 (除非在大多数情况下, 这些循环或switch语句从不被执行).

  有些函数即使声明为内联的也不一定会被编译器内联, 这点很重要; 比如虚函数和递归函数就不会被正常内联. 通常, 递归函数不应该声明成内联函数（注: 递归调用堆栈的展开并不像循环那么简单, 比如递归层数在编译时可能是未知的, 大多数编译器都不支持内联递归函数). 虚函数内联的主要原因则是想把它的函数体放在类定义内, 为了图个方便, 抑或是当作文档描述其行为, 比如精短的存取函数

1.5 #include的路径与顺序

使用标准的头文件包含顺序可增强可读性,避免隐藏依赖:相关头文件,C库,C++库, 其他库的.h,本项目内的.h
1

  项目内头文件应按照项目源代码目录树结构排列, 避免使用 UNIX 特殊的快捷目录"."(当前目录)或“…”（上级目录）。例如google-awesome-project/src/base/logging.h应该按如下方式包含：

#include "base/logging.h"
1

  又如dir/foo.cc或者dir/foo_test.cc的主要作用是实现或测试dir2/foo2.h的供能，foo.cc中包含头文件的次序如下：

1. dir2/foo2.h（优先位置，详情如下）
2. C系统文件
3. C++系统文件
4. 其他库的.h文件
5. 本项目内.h文件

  这种优先的顺序排序保证当dir2/foo2.h遗漏某些必要的库时，dir/foo.cc或dir/foo_test.cc的构建会立刻中止。因此这一条规则保证维护这些文件的人们首先看到构建中止的消息而不是维护其他包的人们
dir/foo.cc和dir2/foo2.h通常在同一目录下（如base/basictypes_unittest.cc和base/basictypes.h），但也可以放在不同目录下。
  按字母顺序分别对每种类型的头文件进行二次排序是不错的主意。注意较老的代码可不符合这条规则，要在方便的时候改正它们。
&emsp 您所依赖的符号 (symbols) 被哪些头文件所定义，您就应该包含（include）哪些头文件，前置声明 (forward declarations) 情况除外。比如您要用到bar.h中的某个符号, 哪怕您所包含的foo.h已经包含了bar.h,也照样得包含bar.h,除非foo.h有明确说明它会自动向您提供bar.h中得symbol。不过凡是cc文件所对应得「相关头文件」已经包含的，就不用再重复包含进其cc文件里面了，就像foo.cc只包含foo.h就够了。不用再管后者所包含得其他内容。举例来说google-awesome-project/src/foo/internal/fooserver.cc得包含次序如下：

#include "foo/public/fooserver.h" // 优先位置
#include <sys/types.h> 
#include <unistd.h>
#include <hash_map>
#include <vector>
#include "base/basictypes.h"
#include "base/commandlineflags.h"
#include "foo/public/bar.h"
1
2
3
4
5
6
7
8

例外：
  有时，平台特定（system-specific）代码需要条件编译（conditional includes），这些代码可以放到其它 includes 之后。当然，您的平台特定代码也要够简练且独立，比如：

#include "foo/public/fooserver.h"
#include "base/port.h" // For LANG_CXX11. #ifdef LANG_CXX11
#include <initializer_list> #endif // LANG_CXX11
1
2
3

结论：

1. 避免多重包含是学编程时最基本的要求
2. 前置声明是为了降低编译依赖，防止修改一个头文件引发多米诺效应
3. 内联函数的合理使用可提高代码执行效率
4. -inl.h可提高代码可读性(一般很少用)
5. 标准化函数参数顺序可以提高可读性和易维护性
6. 包含文件的名称使用“.”和"…"虽然方便却易混乱, 使用比较完整的项目路径看上去很清晰, 很条理, 包含文件的次序除了美观之外, 最重要的是可以减少隐藏依赖, 使每个头文件在“最需要编译” (对应源文件处) 的地方编译, 有人提出库文件放在最后, 这样出错先是项目内的文件, 头文件都放在对应源文件的最前面, 这一点足以保证内部错误的及时发现了
7. 类内部的函数一般会自动内联。所以某函数一旦不需要内联，其定义就不要再放在头文文里，而是放到对应的.cc文件里，这样可以保持头文件的类相当精炼，也很好地贯彻了声明与定义分离的原则
8. 在include中中插入空行以分割相关头文件, C 库, C++ 库, 其他库的和本项目内的是个好习惯。

二、作用域

2.1 命名空间

鼓励在.cc文件内使用匿名命名空间或static声明使用具名的命名空间时, 其名称可基于项目名或相对路径禁止使用using指示。禁止使用内联命名空间
1

定义：
  命名空间将全局作用域细分为独立的, 具名的作用域, 可有效防止全局作用域的命名冲突.
优点：
  虽然类已经提供了（可嵌套的）命名轴线（注：将命名分割在不同类的作用域内），命名空间在这基础上又封装了一层。
  举例来说，两个不同项目的全局作用域都有一个类Foo,这样在编译或运行时造成冲突，如果每个项目将代码置于不同命名空间中，project1::Foo和project2::Foo作为不同符号自然不会冲突。
  内联命名空间会自动把内部的标识符放到外层作用域，比如:

namespace X {
	inline namespace Y {
		void foo();
	}  // namespace Y
}  // namespace X
1
2
3
4
5

X::Y::foo()与X::foo()彼此可代替。内联命名空间主要用来保持跨版本的 ABI 兼容性。
缺点：
  命名空间具有迷惑性, 因为它们使得区分两个相同命名所指代的定义更加困难。
  内联命名空间很容易令人迷惑，毕竟其内部的成员不再受其声明所在命名空间的限制。内联命名空间只在大型版本控制里有用
  有时候不得不多次引用某个定义在许多嵌套命名空间里的实体，使用完整的命名空间会导致代码的冗长
  在头文件中使用匿名空间导致违背 C++ 的唯一定义原则(One Definition Rule(ODR))。
结论：
  根据下文将要提到的策略合理使用命名空间

• 遵守命名空间命名中的规则。
• 像之前的几个例子中一样，在命名空间的最后注释出命名空间的名字
• 用命名空间把文件包含，gflags的声明/定义，以及类的前置声明以外的整个源文件封装起来, 以区别于其它命名空间:

// .h 文 件
namespace mynamespace {
	// 所有声明都置于命名空间中
	// 注意不要使用缩进
	class MyClass {
	public:
		...
			void Foo();
	};
} // namespace mynamespace
1
2
3
4
5
6
7
8
9
10

// .cc 文 件
namespace mynamespace {
	// 函数定义都置于命名空间中
	void MyClass::Foo() {
		...
	}
} // namespace mynamespace
1
2
3
4
5
6
7

  更复杂的.cc文件包含更多, 更复杂的细节, 比如gflags或using声明。

#include "a.h"
DEFINE_FLAG(bool, someflag, false, "dummy flag"); 
namespace a {
	...code for a...
} // namespace a
1
2
3
4
5

• 不要在命名空间std内声明任何东西, 包括标准库的类前置声明,在std命名空间声明实体是未定义的行为, 会导致如不可移植. 声明标准库下的实体, 需要包含对应的头文件。
• 不应该使用using指示引入整个命名空间的标识符号

using namespace foo;
1

• 不要在头文件中使用 命名空间别名 除非显式标记内部命名空间使用。因为任何在头文件中引入的命名空间都会成为公开API的一部分。

// 在 .cc 中使用别名缩短常用的命名空间
namespace baz = ::foo::bar::baz;
1
2

// 在 .h 中使用别名缩短常用的命名空间
namespace librarian {
	namespace impl { // 仅限内部使用
		namespace sidetable = ::pipeline_diagnostics::sidetable;
	} // namespace impl

	inline void my_inline_function() {
		// 限制在一个函数中的命名空间别名
		namespace baz = ::foo::bar::baz;
		...
	}
} // namespace librarian
1
2
3
4
5
6
7
8
9
10
11
12

• 禁止用内联命名空间

2.2 匿名命名空间和静态变量

在.cc文件中定义一个不需要被外部引用的变量时，可以将它们放在匿名命名空间或声明为static。但是不要在.h文件中这么做。
1

定义：
  所有置于匿名命名空间的声明都具有内部链接性，函数和变量可以经由声明为static拥有内部链接性，这意味着你在这个文件中声明的这些标识符都不能在另一个文件中被访问。即使两个文件声明了完全一样名字的标识符，它们所指向的实体实际上是完全不同的。
结论：
  推荐、鼓励在.cc中对于不需要在其他地方引用的标识符使用内部链接性声明，但是不要在.h中使用。
  匿名命名空间的声明和具名的格式相同，在最后注释上namespace:

namespace {
	...
} // namespace
1
2
3

2.3 非成员函数、静态成员函数和全局函数

使用静态成员函数或命名空间内的非成员函数, 尽量不要用裸的全局函数. 将一系列函数直接置于命名空间中，不要用类的静态方法模拟出命名空间的效果，类的静态方法应当和类的实例或静态数据紧密相关
1

优点：
  某些情况下, 非成员函数和静态成员函数是非常有用的, 将非成员函数放在命名空间内可避免污染全局作用域
缺点：
  将非成员函数和静态成员函数作为新类的成员或许更有意义, 当它们需要访问外部资源或具有重要的依赖关系时更是如此
结论：
  有时, 把函数的定义同类的实例脱钩是有益的, 甚至是必要的. 这样的函数可以被定义成静态成员, 或是非成员函数. 非成员函数不应依赖于外部变量, 应尽量置于某个命名空间内. 相比单纯为了封装若干不共享任何静态数据的静态成员函数而创建类, 不如使用 2.1命名空间 。举例而言，对于头文件myproject/foo_bar.h，应当使用：

namespace myproject {
	namespace foo_bar {
		void Function1(); void Function2();
	} // namespace foo_bar
} // namespace myproject
1
2
3
4
5

而非

namespace myproject {
	class FooBar {
	public:
		static void Function1(); static void Function2();
	};
} // namespace myproject
1
2
3
4
5
6

  定义在同一编译单元的函数, 被其他编译单元直接调用可能会引入不必要的耦合和链接时依赖; 静态成员函数对此尤其敏感. 可以考虑提取到新类中, 或者将函数置于独立库的命名空间内
  如果你必须定义非成员函数, 又只是在.cc文件中使用它, 可使用匿名2.1命名空间或static链接关键字（如static int Foo(){…}）限定其作用域。

2.4 局部变量

将函数变量尽可能置于最小作用域内, 并在变量声明时进行初始化
1

  C++ 允许在函数的任何位置声明变量. 我们提倡在尽可能小的作用域中声明变量, 离第一次使用越近越好. 这使得代码浏览者更容易定位变量声明的位置, 了解变量的类型和初始值. 特别是，应使用初始化的方式替代声明再赋值, 比如：

int i;
i = f(); // 坏——初始化和声明分离
1
2

int j = g(); // 好——初始化时声明
1

vector<int> v;
v.push_back(1); // 用花括号初始化更好
v.push_back(2);
1
2
3

vector<int> v = {1, 2}; // 好——v开始就初始化
1

  属于if、while、和for语句的变量应当在这些语句中正常的声明，这样子这些变量的作用域就被限制在这些语句中了，举例说明：

while (const char* p = strchr(str, '/')) 
str = p + 1;
1
2

  有一个例外, 如果变量是一个对象, 每次进入作用域都要调用其构造函数, 每次退出作用域都要调用其析构函数. 这会导致效率降低。

//低效的实现
for(int i = 0; i < 1000000; i++) 
{
	Foo f;	//构造函数和析构函数分别调用 1000000 次!
	f.DoSomething(i);
}
1
2
3
4
5
6

  在循环作用域外面声明这类变量要高效的多：

//构造函数和析构函数只调用1次
Foo f;
for(int i = 0; i < 1000000; i++) 
{
	f.DoSomething(i);
}
1
2
3
4
5
6

2.5 静态和全局变量

禁止定义静态储存周期非POD变量，禁止使用含有副作用的函数初始化POD全局变量，因为多编译单元中的静态变量执行时的构造和析构顺序是未明确的，这将导致代码的不可移植
1

  禁止使用类的 静态储存周期 变量：由于构造和析构函数调用顺序的不确定性，它们会导致难以发现的 bug 。不过constexpr变量除外，毕竟它们又不涉及动态初始化或析构。
  静态生存周期的对象，即包括了全局变量，静态变量，静态类成员变量和函数静态变量，都必须是原生数据类型(POD:Planin Old Data):即int,char和float以及POD类型的指针、数组和结构体。
  静态变量的构造函数、析构函数和初始化的顺序在 C++ 中是只有部分明确的，甚至随着构建变化而变化，导致难以发现的 bug. 所以除了禁用类类型的全局变量，我们也不允许用函数返回值来初始化 POD 变量，除非该函数(比如getenv()或者getpid())不涉及任何全局变量。函数作用域里的静态变量除外，毕竟它的初始化顺序是有明确定义的，而且只会在指令执行到它的声明那里才会发生。
  需要注意的是：同一个编译单元内是明确的，静态初始化优先于动态初始化，初始化顺序按照声明顺序进行，销毁则逆序。不同的编译单元之间初始化和销毁顺序属于未明确行为 (unspecified
behaviour)。
  同理，全局和静态变量在程序中断时会被析构，无论所谓中断是从main()返回还是对exit()的调用。析构顺序正好与构造函数调用的顺序相反。但既然构造顺序未定义，那么析构顺序当然也就不定了。比如，在程序结束时某静态变量已经被析构了，但代码还在跑——比如其他线程——并试图访问它且失败；再比如，一个静态 string 变量也许会在一个引用了前者的其它变量析构之前被析构掉。
  改善以上析构问题的办法之一是用quick_exit()来代替exit()并中断程序。它们的不同之处是前者不会执行任何析构，也不会执行atexit()所绑定的任何 handlers. 如果您想在执行quick_exit()来中断时执行某 handler（比如刷新 log）,我们可以把它绑定到at_quick_exit()。如果想在exit()和quick_exit()都用上该 handler, 都绑定上去。
  综上所述，我们只允许 POD 类型的静态变量，即完全禁用vector(使用 C 数组替代)和string(使用const char[])。
  如果确实需要一个class类型的静态或全局变量，可以考虑在main()函数或pthread_once()内初始化一个指针且永不回收。注意只能用 raw 指针，别用智能指针，毕竟后者的析构函数涉及到上文指出的不定顺序问题。
说明：上文提及的静态变量泛指静态生存周期的对象, 包括: 全局变量, 静态变量, 静态类成员变量,以及函数静态变量
结论：

• cc中的匿名命名空间可避免命名冲突, 限定作用域, 避免直接使用using关键字污染命名空间
• 嵌套类符合局部使用原则, 只是不能在其他头文件中前置声明, 尽量不要public
• 尽量不用全局函数和全局变量, 考虑作用域和命名空间限制, 尽量单独形成编译单元
• 多线程中的全局变量 (含静态成员变量) 不要使用class类型（含STL容器），避免不明确行为导致的 bug
• 作用域的使用, 除了考虑名称污染, 可读性之外, 主要是为降低耦合, 提高编译/执行效率
• 匿名命名空间说白了就是文件作用域，就像 C static 声明的作用域一样，后者已经被 C++标准提倡弃用
• 局部变量在声明的同时进行显式值初始化，比起隐式初始化再赋值的两步过程要高效，同时也贯彻了计算机体系结构重要的概念「局部性（locality）」
• 注意别在循环犯大量构造和析构的低级错误

三、类

类是 C++ 中代码的基本单元. 显然, 它们被广泛使用. 下面列举了在写一个类时的主要注意事项。

3.1 构造函数的职责

不要在构造函数中调用虚函数, 也不要在无法报出错误时进行可能失败的初始化
1

定义
  在构造函数中可以进行各种初始化操作
优点

• 无需考虑类是否被初始化
• 经过构造函数完全初始化后的对象可以为const类型, 也能更方便地被标准容器或算法使用

缺点

• 如果在构造函数内调用了自身的虚函数, 这类调用是不会重定向到子类的虚函数实现. 即使当前没有子类化实现, 将来仍是隐患
• 在没有使程序崩溃 (因为并不是一个始终合适的方法) 或者使用异常 (因为已经被禁用了) 等方法的条件下, 构造函数很难上报错误
• 如果执行失败, 会得到一个初始化失败的对象, 这个对象有可能进入不正常的状态, 必须使用bool isValid()或类似这样的机制才能检查出来, 然而这是一个十分容易被疏忽的方法.构造函数的地址是无法被取得的, 因此, 举例来说,由构造函数完成的工作是无法以简单的方式交给其他线程的。

结论

• 构造函数不允许调用虚函数. 如果代码允许, 直接终止程序是一个合适的处理错误的方式. 否则,考虑用Init()方法或工厂函数
• 构造函数不得调用虚函数, 或尝试报告一个非致命错误. 如果对象需要进行有意义的 (non-
  trivial) 初始化, 考虑使用明确的 Init() 方法或使用工厂模式。Avoid Init() methods on objects
  with no other states that affect which public methods may be called (此类形式的半构造对象有时无法正确工作)

3.2 隐式类型转换

不要定义隐式类型转换. 对于转换运算符和单参数构造函数, 请使用explicit关键字
1

定义
  隐式类型转换允许一个某种类型 (称作 源类型) 的对象被用于需要另一种类型 (称作 目的类型)的位置, 例如, 将一个int类型的参数传递给需要double类型的函数。
  除了语言所定义的隐式类型转换, 用户还可以通过在类定义中添加合适的成员定义自己需要的转换. 在源类型中定义隐式类型转换, 可以通过目的类型名的类型转换运算符实现 (例如operator bool()),在目的类型中定义隐式类型转换, 则通过以源类型作为其唯一参数 (或唯一无默认值的参数) 的构造函数实现。
  explicit关键字可以用于构造函数或 (在 C++11 引入) 类型转换运算符, 以保证只有当目的类型在调用点被显式写明时才能进行类型转换, 例如使用cast。这不仅作用于隐式类型转换, 还能作用于 C++11 的列表初始化语法：

class Foo {
	explicit Foo(int x, double y);
	...
};

void Func(Foo f);
1
2
3
4
5
6

  此时下面的代码是不允许的:

Func({ 42, 3.14 }); // 错误的
1

  这一代码从技术上说并非隐式类型转换, 但是语言标准认为这是explicit应当限制的行为。
优点

• 有时目的类型名是一目了然的, 通过避免显式地写出类型名, 隐式类型转换可以让一个类型的可用性和表达性更强
• 隐式类型转换可以简单地取代函数重载
• 在初始化对象时, 列表初始化语法是一种简洁明了的写法

缺点

• 隐式类型转换会隐藏类型不匹配的错误. 有时, 目的类型并不符合用户的期望, 甚至用户根本没有意识到发生了类型转换
• 隐式类型转换会让代码难以阅读, 尤其是在有函数重载的时候, 因为这时很难判断到底是哪个函数被调用
• 单参数构造函数有可能会被无意地用作隐式类型转换
• 如果单参数构造函数没有加上explicit关键字, 读者无法判断这一函数究竟是要作为隐式类型转换, 还是编码者忘了加上explicit标记。
• 并没有明确的方法用来判断哪个类应该提供类型转换, 这会使得代码变得含糊不清
• 如果目的类型是隐式指定的, 那么列表初始化会出现和隐式类型转换一样的问题, 尤其是在列表中只有一个元素的时候

结论

• 在类型定义中, 类型转换运算符和单参数构造函数都应当用explicit进行标记。一个例外是拷贝和移动构造函数不应当被标记为explicit,因为它们并不执行类型转换. 对于设计目的就是用于对其他类型进行透明包装的类来说, 隐式类型转换有时是必要且合适的. 这时应当联系项目组长并说明特殊情况
• 不能以一个参数进行调用的构造函数不应当加上explicit。接受一个std::initializer_list作为参数的构造函数也应当省略explicit，以便支持拷贝初始化(例如 Mytype num = {1,2}
  声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/菜鸟追梦旅行/article/detail/386528?site