Google 保持其一贯的严谨精神, 5 万汉字的指南涉及广泛, 论证严密. 我们翻译该系列指南的主因也正是其严谨性. 严谨意味着指南的价值不仅仅局限于它罗列出的规范, 更具参考意义的是它为了列出规范而做的谨慎权衡过程.Google主导的开源项目均符合本指南的规定注意:本指南并非C++教程,我们假定读者已经对C++非常熟悉.Docs》C艹+风格捐南-内容目录》1.头文件1.头文件通常每一个c文件都有一个对应的h文件也有一些常见例外如单元测试代码和只包含ain)函数的c文件正确使用头文件可令代码在可读性、文件大小和性能上大为改观.下面的规则将引导你规避使用头文件时的各种陷阱11.Self- contained头文件U Tip头文件应该能够自给自足(sef- contained,也就是可以作为第一个头文件被引入),以h结尾。至于用来插入文本的文件,说到底它们并不是头文件,所以应以.inc结尾。不允许分离出-in1.h头文件的做法所有头文件要能够自给自足。换言之,用户和重构工具不需要为特别场合而包含额外的头文件。详言之,一个头文件要有1.2.# define保护,统统包含它所需要的其它头文件,也不要求定义任何特别 symbols不过有一个例外,即一个文件并不是 self-contained的,而是作为文本插入到代码某处。或者,文件内容实际上是其它头文件的特定平台( platform- specific)扩展部分。这些文件就要用nc文件扩展名如果h文件声明了一个模板或内联函数,同时也在该文件加以定义。凡是有用到这些的文件,就得统统包含该头文件,否则程序可能会在构建中链接失败。不要把这些定义放到分离的-in1.h文件里(译者注∶过去该规范曾提倡把定义放到-nlh里过)。有个例外:如果某函数模板为所有相关模板参数显式实例化,或本身就是某类的-个私有成员,那么它就只能定义在实例化该模板的,c文件里12.# define保护O Ti所有头文件都应该使用# efine来防止头文件被多重包含,命名格式当是
H为保证唯一性,头文件的命名应该基于所在项目源代码树的全路径例如,项目+0中的头文件fo/src/bar/bazh可按如下方式保护#ifndef foo#define FooBABA乙日#endif// FO0 BAR BAZ H13.前置声明O Tip尽可能地避免使用前置声明。使用#ncue包含需要的头文件即可。定义所谓「前置声明」( forward declaration)是类、函数和模板的纯粹声明,没伴随着其定义优点:前置声明能够节省编译时间,多余的# include会迫使编译器展开更多的文件,处理更多的输入。前置声明能够节省不必要的重新编译的时间。t# nclude使代码因为头文件中无关的改动而被重新编译多次。缺点前置声明隐藏了依赖关系,头文件改动时,用户的代码会跳过必要的重新编译过程前置声明可能会被库的后续更改所破坏。前置声明函数或模板有时会妨碍头文件开发者变动其AP.例如扩大形参类型,加个自带默认参数的模板形参等等。前置声明来自命名空间std:的 symbol时,其行为未定义。很难判断什么时候该用前置声明,什么时候该用# include。极端情况下,用前置声明代替 includes甚至都会暗暗地改变代码的含义struct B 0;struct d: B X// good user,Cc:#include b hvoid f(B*);void f(void*);void test (D* x) f(x;// caLls f(b+如果# include被B和的前置声明替代,test()就会调用f(vid)前置声明了不少来自头文件的 symbol时,就会比单单一行的 include冗长仅仅为了能前置声明而重构代码(比如用指针成员代替对象成员)会使代码变得更慢更复杂结论尽量避免前置声明那些定义在其他项目中的实体函数:总是使用# include类模板:优先使用|# include至于什么时候包含头文件,参见15.# Include的路径及顺序。14.内联函数O Tip只有当函数只有10行甚至更少时才将其定义为内联函数定义:当函数被声明为内联函数之后,编译器会将其内联展开,而不是按通常的函数调用机制进行调用优点:只要内联的函数体较小,内联该函数可以令目标代码更加高效.对于存取函数以及其它函数体比较短,性能关键的函数,鼓励使用内联缺点滥用内联将导致程序变得更慢.内联可能使囯标代码量或増或減,这取决于内联函数的大小内联非常短小的存取函数通常会减少代码大小,但内联一个相当大的函数将戏剧性的增加代码大小.现代处理器由于更好的利用了指令缓存,小巧的代码往往执行更快。结论:一个较为合理的经验准则是,不要内联超过10行的函数谨慎对待析构函数,析构函数往往比其表面看起来要更长,因为有隐含的成员和基类析构函数被调用!另一个实用的经验准则:内联那些包含循环或 switch语句的函数常常是得不偿失(除非在大多数情况下,这些循环或 switch语句从不被执行)有些函数即使声明为内联的也不一定会被编译器内联,这点很重要;比如虚函数和递归函数就不会被正常内联通常,递归函数不应该声明成内联函数.( Yule Fox注:递归调用堆栈的展开并不像循环那么简单,比如递归层数在编译时可能是未知的,大多数编译器都不支持内联递归函数).虚函数内联的主要原因则是想把它的函数体放在类定义内,为了图个方便,抑或是当作文档描述其行为,比如精短的存取函数.1.5.# include的路径及顺序O Tip使用标准的头文件包含顺序可增强可读性,避免隐藏依赖:相关头文件,C库,C++库,其他库的h本项目内的h项目内头文件应按照项目源代码目录树结构排列,避免使用∪NX特殊的快捷目录·(当前目录)或(上级目录)例如, google- awe some- project/src/base/ logging.h应该按如下方式包含#include"base/logging. h又如,dir/oc或dir/ foo_test.c的主要作用是实现或测试dir2/o2.h的功能,foc中包含头文件的次序如下1.dir2/foo2h(优先位置,详情如下2.C系统文件3.C++系统文件4.其他库的h文件5本项目内h文件这种优先的顺序排序保证当dir2/.h遗漏某些必要的库时,dir/foc或dr/6 o_test.cc.构建会立刻中止。因此这一条规则保证维护这些文件的人们首先看到构建中止的消息而不是维护其他包的人们。dr/6oc和dir2/fo0.h通常位于同一目录下(如base/ basictypes_unittest.c和base/ basictypes,h),但也可以放在不同目录下按字母顺序分别对每种类型的头文件进行二次排序是不错的主意。注意较老的代码可不符合这条规则,要在方便的时候改正它们。您所依赖的符号⑤ symbols被哪些头文件所定义,您就应该包含( include)哪些头文件,前置声明( forward declarations)情况除外。比如您要用到bar.h中的某个符号,哪怕您所包含的fo.h已经包含了ban.h,也照样得包含bar.h,除非fo.h有明确说明它会自动向您提供brh中的smbo不过,凡是c文件所对应的「相关头文件」已经包含的,就不用再重复包含进其cc文件里面了,就像o.c只包含fo.h就够了,不用再管后者所包含的其它内举例来说, google- awesome- project/src/fo/ nternal/ fooserver:c的包含次序如下:# include"foo/ public/ observer,h"//优先位置#include #include # include< hash map〉#include Include"base/basictypes h#include"base/commandlineflagsh#include" foo/publicbar. h例外有时,平台特定( systen- specific)代码需要条件编译( conditional includes),这些代码可以放到其它 includes之后。当然,您的平台特定代码也要够简练且独立,比如:#includefoo/public/fooserver hInclude"base/port. h"// For LANG CXX11#主 Fdef LANG CXX11#include fendiANG CXX11译者( YuleFox)笔记1.避免多重包含是学编程时最基本的要求;2.前置声明是为了降低编译依赖,防止修改一个头文件引发多米诺效应;3.内联函数的合理使用可提高代码执行效率;4.-in.h可提高代码可读性(一般用不到吧D5.标准化函数参数顺序可以提高可读性和易维护性(对函数参数的堆栈空间有轻微影响,我以前大多是相同类型放在一起);6.包含文件的名称使用·和虽然方便却易混乱,使用比较完整的项目路径看上去很清晰,很条理,包含文件的次序除了美观之外,最重要的是可以减少隐藏依赖,使每个头文件在最需要编译”(对应源文件处:)的地方编译,有人提岀库文件放在最后,这样岀错先是项目内的文件,头文件都放在对应源文件的最前面,这一点足以保证内部错误的及时发现了译者( acgtyrant)笔记1.原来还真有项目用# includes来插入文本,且其文件扩展名inc看上去也很科学。2. Google已经不再提倡in1.h用法。3注意,前置声明的类是不完全类型( incomplete type),我们只能定义指向该类型的指针或引用,或者声明(但不能定义)以不完全类型作为参数或者返回类型的函数。毕竟编译器不知道不完全类型的定义,我们不能创建其类的任何对象,也不能声明成类内部的数据成员4.类内部的函数一般会自动内联。所以某函数一旦不需要内联,其定义就不要再放在头文件里,而是放到对应的.c文件里。这样可以保持头文件的类相当精炼,也很好地贯彻了声明与定义分离的原则。5在# nclude中插入空行以分割相关头文件,C库C+库,其他库的h和本项目内的h是个好习惯。DoCs》C++风格指南-内容目录》2.作用域2.作用城21.命名空间UTip鼓励在c文件内使用匿名命名空间或 static声明使用具名的命名空间时,其名称可基于项目名或相对路径.禁止使用 using指示( using- directive)。禁止使用内联命名空间inline namespace)。定义命名空间将全局作用域细分为独立的,具名的作用域,可有效防止全局作用域的命名冲突优点虽然类已经提供了(可嵌套的)命名轴线( ulefox注:将命名分割在不同类的作用域内)命名空间在这基础上又封装了一层举例来说,两个不同项目的全局作用域都有一个类F,这样在编译或运行时造成冲突.如果每个项目将代码置于不同命名空间中, project1:o和 project2:Fo作为不同符号自然不会冲突内联命名空间会自动把内部的标识符放到外层作用域,比如namespace x iinline namespace Y ivoid foo(name space y/ name space X:y:fo()与x:fo()彼此可代替。内联命名空间主要用来保持跨版本的AB|兼容性。缺点 
