Google 编程规范本地化、简化。如有需要，可参考 Google C++ code style guide原文：
http://google.github.io/styleguide/cppguide.html
本文档基于网上流传的Google C++编程风格指南，由 edisonpeng（2009/3/25）整理
本地化简化由MISAS开发团队使用。在此分享以供各开发团队参考。
目录
背景
C ++是许多Google开源项目使用的主要开发语言之一。正如每个C ++程序员都知道的那样，该语言具有许多强大的功能，但是这种功能带来了复杂性，这反过来又会使代码更容易出错并且难以阅读和维护。
本指南的目标是通过详细描述编写C ++代码的注意事项来管理这种复杂性。存在这些规则是为了使代码库易于管理，同时仍允许编码人员高效地使用C ++语言功能。
代码风格，也称为可读性，就是我们称之为管理C ++代码的约定。Style这个术语有点用词不当，因为这些约定涵盖的不仅仅是源文件格式。
Google开发的大多数开源项目都符合本指南的要求。
请注意，本指南不是C++教程：我们假设读者熟悉该语言。
头文件
通常，每个.cc文件都应该有一个关联的.h文件。有一些常见的例外，例如单元测试和.cc仅包含main()函数的小文件 。
正确使用头文件会对代码的可读性，大小和性能产生巨大影响。
以下规则将指导您使用头文件的各种麻烦。
#define 保护
所有头文件都应该有#define防护，以防止多次包含。符号名称的格式应为
<PROJECT>_<PATH>_<FILE>_H_
为了保证唯一性，它们应该基于项目源树中的完整路径。例如，foo/src/bar/baz.h项目中的文件foo应具有以下保护：
#ifndef FOO_BAR_BAZ_H_
#define FOO_BAR_BAZ_H_
...
#endif // FOO_BAR_BAZ_H_头文件依赖
使用前置声明，尽量减少.h文件中#influde的数量。
当一个头文件被包含的同时也引入了一项新的依赖（dependency），只要该头文件被修改，代码就要重新编译。如果你的头文件包含了其他头文件，返些头文件的任何改变也将导致那些包含了你的头文件的代码
重新编译。因此，我们应该尽量少的包含头文件，尤其是那些包含在其他头文件中的。
使用前置声明可以显著减少需要包含头文件的数量。举例说明：头文件中用到类File，但不需要访问File的声明，则头文件中只需前置声明
class File
无需
include "file/base/file.h"
注：能依赖声明就不要依赖定义。
内联函数
只有当函数规模在10行以内才会将其定义为内联函数（inline function）.
定义： 当函数被声明为内联函数之后，编译器可能会将其内联展开，无需按照通常的函数调用机制调用内联函数。
优点：
当函数体较小时，内联该函数可令目标代码更加高效。比如存取函数及其他较短的关键执行函数。
缺点：
滥用内联会导致程序变慢。内联后，目标代码增加、或减少取决于内联函数的大小。内联函数短小会减少代码量，但内联一个很大的函数，将会显著增加代码量。
结论：
规则1：不要内联超过10行的函数。慎重对待析构函数，因为有一些隐式成员和基类析构函数要调用，所以析构函数比其表面看起来要长。
规则2：不要内联包含循环或switch语句的函数，除非大多数时候这些语句从不执行。
重要：
虚函数和地柜函数堆栈调用展开复杂，通常编译器不支持，同时也不应该将其定义为内联函数。
-inl.h文件
复杂的内联函数定义，应放在后缀名为-inl.h的头文件中。
和其他头文件一样，也需要#define保护。
函数参数顺序
定义参数时，参数顺序为：输入参数在前，输出参数在后。
输入参数为传值或常数引用，输出参数为非常数指针。
本条应尽量遵守，类或结构体中的输入输出两用参数作为中间参数。
包含头文件的名词及次序
包含次序标准化可增强可读性，避免依赖。次序为：C库、C++库、其他库的.h、项目内的.h。
即：
C系统文件
C++系统文件
其他库头文件
本项目内头文件
项目内头文件按照项目源码的目录树结构排序，避免使用UNIX路径.和..
总结：
（1）避免多重包含
（2）前置声明是为了降低编译依赖，防止修改一个头文件引发多米诺效应
（3）内联函数的合理使用可提高代码的执行效率
（4）-inl.h可提高代码可读性
（5）标准化函数参数顺序可提高可读性和易维护性
（6）包含文件使用.和..虽然方便，却易混乱，使用完整项目路径更清晰、美观。