c编码规范google.docx
《c编码规范google.docx》由会员分享，可在线阅读，更多相关《c编码规范google.docx（5页珍藏版）》请在冰豆网上搜索。
c编码规范google
竭诚为您提供优质文档/双击可除
c,,编码规范,google
篇一：
google_c++编码规范中文版
googlec++编程风格指南
edisonpeng整理20xx/3/25
目录
背景........................
........................................................................................................................3
头文件............................................................................................................................................4
作用域............................................................................................................................................8
类..................................................................................................................................................13
来自google的奇技..................................................................................................................20
其他c++特性...............................................................................................................................32
命名约定........................................................................................................................................32
注释................................................................................................................................................38
格式..............................................................................................................................................44
规则特例........................................................................................................................................57
背景c++是google大部分开源项目的主要编程语言.正如每个c++程序员都知道的,c++有很多强大的特性,但这种强大不可避免的导致它走向复杂，使代码更容易产生bug,难以阅读和维护.
本指南的目的是通过详细阐述c++注意事项来驾驭其复杂性.这些规则在保证代码易于管理的同时,高效使用c++的语言特性.
风格,亦被称作可读性,也就是指导c++编程的约定.使用术语―风格‖有些用词不当,因为这些习惯远不止源代码文件格式化这么简单.
使代码易于管理的方法之一是加强代码一致性.让任何程序员都可以快速读懂你的代码这点非常重要.保持统一编程风格并遵守约定意味着可以很容易根据―模式匹配‖规则来推断各种标识符的含义.创建通用,必需的习惯用语和模式可以使代码更容易理解.在一些情况下可能有充分的理由改变某些编程风格,但我们还是应该遵循一致性原则，尽量不这么做.本指南的另一个观点是c++特性的臃肿.c++是一门包含大量高级特性的庞大语言.某些情况下,我们会限制甚至禁止使用某些特性.这么做是为了保持代码清爽,避免这些特性可能导致的各种问题.指南中列举了这类特性,并解释为什么这些特性被限制使用.
google主导的开源项目均符合本指南的规定.
注意:
本指南并非c++教程,我们假定读者已经对c++非常熟悉.
1、头文件
通常每一个.cc文件都有一个对应的.h文件.也有一些常见例外,如单元测试代码和只包含main（）函数的.cc文件.
正确使用头文件可令代码在可读性、文件大小和性能上大为改观.
下面的规则将引导你规避使用头文件时的各种陷阱.
1.1.#define保护
tip
所有头文件都应该使用#define防止头文件被多重包含,命名格式当是:
_ __h_为保证唯一性,头文件的命名应该依据所在项目源代码树的全路径.例如,项目foo中的头文件foo/src/bar/baz.h可按如下方式保护:
#ifndefFoo_baR_baz_h_
#defineFoo_baR_baz_h_
…
#endif//Foo_baR_baz_h_
1.2.头文件依赖
tip
能用前置声明的地方尽量不使用#include.
当一个头文件被包含的同时也引入了新的依赖,一旦该头文件被修改,代码就会被重新编译.如果这个头文件又包含了其他头文件,这些头文件的任何改变都将导致所有包含了该头文件的代码被重新编译.因此,我们倾向于减少包含头文件,尤其是在头文件中包含头文件.
使用前置声明可以显著减少需要包含的头文件数量.举例说明:
如果头文件中用到类File,但不需要访问File类的声明,头文件中只需前置声明classFile;而无须#include"file/base/file.h".
不允许访问类的定义的前提下,我们在一个头文件中能对类Foo做哪些操作
我们可以将数据成员类型声明为Foo*或Foo比如虚函数和递归函数就不会被正常内联.通常,递归函数不应该声明成内联函数.（yuleFox注:
递归调用堆栈的展开并不像循环那么简单,比如递归层数在编译时可能是未知的,大多数编译器都不支持内联递归函数）.虚函数内联的主要原因则是想把它的函数体放在类定义内,为了图个方便,抑或是当作文档描述其行为,比如精短的存取函数.
1.4.-inl.h文件
tip
复杂的内联函数的定义,应放在后缀名为-inl.h的头文件中.
内联函数的定义必须放在头文件中,编译器才能在调用点内联展开定义.然而,实现代码理论上应该放在.cc文件中,我们不希望.h文件中有太多实现代码,除非在可读性和性能上有明显优势.
如果内联函数的定义比较短小,逻辑比较简单,实现代码放在.h文件里没有任何问题.比如,存取函数的实现理所当然都应该放在类定义内.出于编写者和调用者的方便,较复杂的内联函数也可以放到.h文件中,如果你觉得这样会使头文件显得笨重,也可以把它萃取到单独的-inl.h中.这样把实现和类定义分离开来,当需要时包含对应的-inl.h即可。
-inl.h文件还可用于函数模板的定义.从而增强模板定义的可读性.
别忘了-inl.h和其他头文件一样,也需要#define保护.
1.5.函数参数的顺序
tip
定义函数时,参数顺序依次为:
输入参数,然后是输出参数.
c/c++函数参数分为输入参数,输出参数,和输入/输出参数三种.输入参数一般传值或传const引用,输出参数或输入/输出参数则是非-const指针.对参数排序时,将只输入的参数放在所有输出参数之前.尤其是不要仅仅因为是新加的参数,就把它放在最后;即使是新加的只输入参数也要放在输出参数之前。
这条规则并不需要严格遵守.输入/输出两用参数（通常是类/结构体变量）把事情变得复杂,为保持和相关函数的一致性,你有时不得不有所变通.
篇二：
google-c++编程规范（完整）
背景google的开源项目大多使用c++开发。
每一个c++程序员也都知道，c++具有很多强大的语言特性，但这种强大不可避免的导致它的复杂，这种复杂会使得代码更易于出现bug、难于阅读和维护。
本指南的目的是通过详细阐述在c++编码时要怎样写、不要怎样写来规避其复杂性。
这些规则可在允许代码有效使用c++语言特性的同时使其易于管理。
风格，也被视为可读性，主要指称管理c++代码的习惯。
使用术语风格有点用词不当，因为这些习惯远不止源代码文件格式这么简单。
使代码易于管理的方法之一是增强代码一致性，让别人可以读懂你的代码是很重要的，保持统一编程风格意味着可以轻松根据“模式匹配”规则推断各种符号的含义。
创建通用的、必需的习惯用语和模式可以使代码更加容易理解，在某些情况下改变一些编程风格可能会是好的选择，但我们还是应该遵循一致性原则，尽量不这样去做。
本指南的另一个观点是c++特性的臃肿。
c++是一门包含大量高级特性的巨型语言，某些情况下，我们会限制甚至禁止使用某些特性使代码简化，避免可能导致的各种问题，指南中列举了这类特性，并解释说为什么这些特性是被限制使用的。
由google开发的开源项目将遵照本指南约定。
注意：
本指南并非c++教程，我们假定读者已经对c++非常熟悉。
头文件
通常，每一个.cc文件（c++的源文件）都有一个对应的.h文件（头文件），也有一些例外，如单元测试代码和只包含main（）的.cc文件。
正确使用头文件可令代码在可读性、文件大小和性能上大为改观。
下面的规则将引导你规避使用头文件时的各种麻烦。
1.#define的保护
所有头文件都应该使用#define防止头文件被多重包含（multipleinclusion），命名格式当是：
_ __h_
为保证唯一性，头文件的命名应基于其所在项目源代码树的全路径。
例如，项目foo中的头文件foo/src/bar/baz.h按如下方式保护：
#ifndefFoo_baR_baz_h_
#defineFoo_baR_baz_h_
...
#endif//Foo_baR_baz_h_
1
2.头文件依赖
使用前置声明（forwarddeclarations）尽量减少.h文件中#include的数量。
当一个头文件被包含的同时也引入了一项新的依赖（dependency），只要该头文件被修改，代码就要重新编译。
如果你的头文件包含了其他头文件，这些头文件的任何改变也将导致那些包含了你的头文件的代码重新编译。
因此，我们宁可尽量少包含头文件，尤其是那些包含在其他头文件中的。
使用前置声明可以显著减少需要包含的头文件数量。
举例说明：
头文件中用到类File，但不需要访问File的声明，则头文件中只需前置声明classFile;无需#include"file/base/file.h"。
在头文件如何做到使用类Foo而无需访问类的定义？
1）将数据成员类型声明为Foo*
升级会员 