自己最新整理的Google代码规范，方便大家学习使用，可以节省大家整理时间。3.4.拷贝构造凶数::::.::.a.a:::::::B:::::.::a:::::..:::.:a::::.:.::::::a:::::::3.5.结构体VS.类…243.6.继承…243.7.多重继承3.8.接口….253.9.运算符重载…263.10.存取控制.283.11.声明顺序…18译者( Yulefox)笔记.::.:.a:∴284.函数294.1.参数顺序4.2编写简短函数.294.3.引用参数…294.4.函数重载304.5缺省参数…314.6.函数返回类型后置语法315.来自 Google的奇技…5.1所有权与智能指针….335.2. cpplint.…34译者( acgtyrant)笔记…346.其他C++特性…356.1.引用参数.36.2.右值引用…....::::::.:·:::::.:::.::.:356.3.函数重载.3664.缺省参数..6.5.变长数组和 alloca06.6.友元386.7.异常3868.运行时类型识别69.类型转换6.10.流·.:.:::.::.::.:..:.::..是:::::.:::::..,:,416.11.前置自增和自减……426.12. const用法.…6.13. constexpr用法446.14.整型.…46.15.64位下的可移植性466.16.预处理宏6.17.0, nullptr和NULL476. 18. sizeof486.19.autO…………486.20.列表初始化6.21. Lambda表达式516.22.模板编程623. Boost库.536.24.C++11……154译者( acgtyrant)笔记557.命名约定567.1.通用命名规则567.2.文件命名567.3.类型命名577.4.变量命名.7.5.常量命名587.6.函数命名·.:.:::.::.::.:..:.:::::...是:::::.::::.:587.7.名字空间命名597.8.枚举命名79.宏命名…607.10.命名规则的特例60详者( acgtyrant)笔记,618.注释8.1.注释风格.628.2.文什注释8.3.类注释628.4.函数注释8.5.变量注释,648.6.实现注释87.标点,拼写和语法.678.8.TODO注释……:.::::::...·::::·:··::::678.8弃用注释·,,68译者( YuleFox)笔记689.格式699.1.行长度…9.2.非ASC字符…699.3.空格还是制表位.709.4.函数声明与定义…709 Lambda表达式….::.:.a:灬729.6.函数调用9.7列表初始化格式9.8条件语句…759.9循环和开关选择语句…779.10.针和引用表达式…789.11.尔表达式…9.12.函数返回值799.13变量及数组初始化9.14.预处理指令…809.15.类格式9.16初始化列衣819.17.命名空间格式化9.18.平留白.839.19.垂直留白84译者( Yulefox)笔记85译者( acgtyrant)笔记….8510.规则特例8610.1.现有不合规范的代码…….8610.2.Wⅰ ndows代码…8611.结束语背景C++是 Google大部分开源攻目的主要编程语言.正如每个C++程序员都知道的,C++有很多强大的特性,但这种照大不可避免的导致它走冋复杂,使代码更容易产生bug,难以阅读和维扩本指南的目的是通过详细阐述C++注意事项来驾驭其复杂性.这些规则在保证代码易丁管理的叵时,也能高效使用C++的语言特性风格,亦被称作可读性,也就是指导C++编程的约定.使用术语“风格”有些用词不当,因为这些习贯远不止源代码文件格式化这么简单使代码易于管理的方法之一是加强代码一致性.让任何程序员都可以快速读懂你的代码这点非常重要.保持统一掮程风格并遵守约定意呔着可以很容易根据“模式匹巸”规则来推断各和标识符的含义.创建運用,必需釣习惯用语和模式可以使代码更容易理解.在一些情况丶可能有充分的理由改变某些编程风格,但我们还是应该遵循一致性原则,尽量不这么倣本指南的另一个观点是C++特性的臃胂.C艹十是一门包含大量高级特性的庞大语言.某些情况下,我们会限制芸至禁止使用某些特性.这么做是为了保持代码清爽,邂免这些特性可能导敛的各种问题.指南中外举了这类特性,并解释为什么这特性被限制使用Google主导的开源项目均筲合本指南的规定注意:本指南并非C++教程,我们假定读者己经对C++非常熟悉1.头文件通常每一个,cc文件都有一个对应的.h文件,也有一些常见例外,如单元测试代码和只包含main()函数的.cc文正痈使用头文件可令代码在可读性、文件大小和性能上大为改观卜面的規则将引导你規避使用头文件时的各种陷阱1.1.Sef- contained头文件头文件应该能够自给自足( self- contained,就是可以作为第一个头文什被引入),以,h结尾。至于用来插入文本的文件,说到底它们并不是头文作,所以应以.inc结尾。不允许分离出-inl.h头文件的做法.所有头文件要能够自给自足换言之,用户和重构下具不需要为特别场合而包含额外的头文件,详言之,个头文件要有1.2# define保护,统统包含它所需要的其它头文件,也不耍求定义任何特别 symbols不过有一个例外,即一个文件并不是self- contained的,而是作为文本插入到代码某处。或者,文件内容实际上是其它头文件的特定平台( platform- specific)扩展韶分。这些文件就要用,inc文件扩展名。如果.h文件声明了一个模板或内联函数,同时也在该文件加以定义。凡是有用到这些的,cc文件,就得统统包含该头文件,否贝程序可能会在枃銈屮链接失败。不要把这些定义放到分离的-in.h文件里(译者注:过去该规范曾提倡把定义放到-inlh里过)有个例外:如果某函数模板为所有相关模板参数显式实例化,或本身就是某类白一个私有成员,那么它就只能定义在实例化该模板的,c文件里。1.2.# define保护Tip所有头文作都应该使用# define防止头文件被多重包含,命名格式当是:< PROJECT>
H为保证唯一性,头文件的命名应该依採所在项目源代码树的全路径.例如,项目fo中的头文件foo/src/bar/baz.h可按如下方式保护#ifndef Foo bar BAZ h#define Foo BAr BAZ h#endif// FO0 BAR BAZ H13.前置声明Tip尽可能地燈免使用前置声呒。使用# include包含需娈的头文件即可。定义:所谓「前置声明」( forward declaration冫是类、κ数和模板的纯粹声眀,没伴随着其定义优点·前置声明能够节省编译时间,多余的# include会迫使编译器展开更多的文件,处理更多的输入。前置声匪能够节省不必要的重新编译的时间。# include使代码因为头文件中无关的改动而被重新编译多次缺点:前置声隐藏了依颋关系,头文件改动时,用户的代砢会跳过必要的重新编译过程。前置声明可能会被库的后续更改所破坏。前置声明函效或模板有时公妨碍头文件开发者变动其Al.例如护大形参类型,加个白带默认参数的模饭形参等等。前置声明来自命名空间std::的 symbol时,其行为未定义。很难判断什么时候该用前置声明,什么时候该用# include。极端情况卜,用前置声明代替 includes甚至都会暗暗地改变代码的含义struct Bstruct D: B 0// good_ user.cc#inc lude "b, hvoid f(B*):void f(void*)void test(D* x)f(x);// calls f(B*)如果# include被B和D的前置声明替代,test()就会调用f(void*)·前置声明了不少来白头文作的 symbol时,就会比单单一行的inc1uce冗长。·仅仅为了能前置声明而重构代码(比如用指针成员代替对象成员)会使代码变得更慢更复杂.结论:尽量避免前置声明那些定义在其他项目屮的实体函数:总是使用# include类模板:优先使用#inc1至于什么时候包含头文件,参见1.5.# Include的路径及顺序。 
