谷歌C++编程风格指南(英文版)

需积分: 3 158 浏览量更新于2024-07-30 收藏 778KB DOC 举报

本资源是一份由Google官方发布的C++编码风格指南（Google C++ Style Guide），版本为3.188。该文档是英文版的，旨在提供一套Google内部推荐的C++编程规范，旨在提高代码的可读性、一致性以及维护性。文档内容涵盖了多个关键主题，如头文件管理、函数参数顺序、命名约定、作用域规则、类的设计与继承、智能指针、特殊C++特性如引用参数和异常处理，以及Google特有的编程实践，如`cpplint`检查工具。 1. **Header Files**: - 强调使用`#define Guard`来避免重复包含问题。 - 鼓励将函数依赖项声明在inline函数的`.inl.h`文件中，以提高效率和模块化。 2. **Function Parameter Ordering**: - 规范了函数参数的顺序，通常先声明常量参数，后声明可变参数，以便于理解和调试。 3. **Names and Order of Includes**: - 指出在命名空间、类或函数定义中应遵循特定的包括顺序，以减少编译时错误。 4. **Scoping**: - 讨论了命名空间的使用，以避免命名冲突。 - 提到嵌套类、非成员静态成员函数、全局函数以及局部变量和静态/全局变量的区别和使用场景。 5. **Classes**: - 强调在构造函数中执行必要的初始化工作，区分默认构造器、显式构造器和拷贝构造器。 - 探讨结构体与类的选择，以及多继承的注意事项。 - 提倡接口设计和运算符重载，同时关注访问控制和声明顺序。 - 倡导编写简洁的函数，以降低复杂性。 6. **Google-Specific**: - `SmartPointers`：推荐使用智能指针来管理对象生命周期，以防止内存泄漏。 - `cpplint`：介绍Google的代码质量检查工具，用于检测编码规范遵守情况。 7. **Other C++ Features**: - 使用引用参数以提高效率，同时讨论函数重载和默认参数的合理应用。 - 变长数组和`alloca()`的使用，以及其潜在风险。 8. **Exceptions and Run-Time Type Information (RTTI)**: - 探讨如何处理异常，并提及运行时类型信息在某些场景下的应用。这份指南是Google工程师们在实践中总结的最佳实践，遵循这些规范可以让你的C++代码更符合业界标准，有助于团队间的协作和代码审查。学习并遵循这些规则，能够提升代码质量，减少维护成本，同时也有助于适应Google的开发环境和工具链。

...

};

Pros: This is useful when the nested (or member) class is only used by the enclosing class; making it a member

puts it in the enclosing class scope rather than polluting the outer scope with the class name. Nested classes can

be forward declared within the enclosing class and then defined in the .cc file to avoid including the nested class

definition in the enclosing class declaration, since the nested class definition is usually only relevant to the

implementation.

Cons: Nested classes can be forward-declared only within the definition of the enclosing class. Thus, any header

file manipulating a Foo::Bar* pointer will have to include the full class declaration for Foo.

Decision: Do not make nested classes public unless they are actually part of the interface, e.g., a class that holds a

set of options for some method.

Nonmember, Static Member, and Global Functions

link ▽

Prefer nonmember functions within a namespace or static member functions to global functions; use completely

global functions rarely.

Pros: Nonmember and static member functions can be useful in some situations. Putting nonmember functions in a

namespace avoids polluting the global namespace.

Cons: Nonmember and static member functions may make more sense as members of a new class, especially if

they access external resources or have significant dependencies.

Decision:

Sometimes it is useful, or even necessary, to define a function not bound to a class instance. Such a function can

be either a static member or a nonmember function. Nonmember functions should not depend on external

variables, and should nearly always exist in a namespace. Rather than creating classes only to group static

member functions which do not share static data, use namespaces instead.

Functions defined in the same compilation unit as production classes may introduce unnecessary coupling and link-

time dependencies when directly called from other compilation units; static member functions are particularly

susceptible to this. Consider extracting a new class, or placing the functions in a namespace possibly in a separate

library.

If you must define a nonmember function and it is only needed in its .cc file, use an unnamed namespace or

static linkage (eg static int Foo() {...}) to limit its scope.

Local Variables

link ▽

Place a function's variables in the narrowest scope possible, and initialize variables in the declaration.

C++ allows you to declare variables anywhere in a function. We encourage you to declare them in as local a scope

as possible, and as close to the first use as possible. This makes it easier for the reader to find the declaration and

see what type the variable is and what it was initialized to. In particular, initialization should be used instead of

declaration and assignment, e.g.

int i;

i = f(); // Bad -- initialization separate from declaration.

int j = g(); // Good -- declaration has initialization.

Note that gcc implements for (int i = 0; i < 10; ++i) correctly (the scope of i is only the scope of the

for loop), so you can then reuse i in another for loop in the same scope. It also correctly scopes declarations in

if and while statements, e.g.

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

There is one caveat: if the variable is an object, its constructor is invoked every time it enters scope and is created,

and its destructor is invoked every time it goes out of scope.

// Inefficient implementation:

for (int i = 0; i < 1000000; ++i) {

Foo f; // My ctor and dtor get called 1000000 times each.

f.DoSomething(i);

}

It may be more efficient to declare such a variable used in a loop outside that loop:

Foo f; // My ctor and dtor get called once each.

for (int i = 0; i < 1000000; ++i) {

f.DoSomething(i);

}

Static and Global Variables

link ▽

Static or global variables of class type are forbidden: they cause hard-to-find bugs due to indeterminate order of

construction and destruction.

Objects with static storage duration, including global variables, static variables, static class member variables, and

function static variables, must be Plain Old Data (POD): only ints, chars, floats, or pointers, or arrays/structs of

POD.

The order in which class constructors and initializers for static variables are called is only partially specified in C++

and can even change from build to build, which can cause bugs that are difficult to find. Therefore in addition to

banning globals of class type, we do not allow static POD variables to be initialized with the result of a function,

unless that function (such as getenv(), or getpid()) does not itself depend on any other globals.

Likewise, the order in which destructors are called is defined to be the reverse of the order in which the

constructors were called. Since constructor order is indeterminate, so is destructor order. For example, at program-

end time a static variable might have been destroyed, but code still running -- perhaps in another thread -- tries to

access it and fails. Or the destructor for a static 'string' variable might be run prior to the destructor for another

variable that contains a reference to that string.

As a result we only allow static variables to contain POD data. This rule completely disallows vector (use C

arrays instead), or string (use const char []).

If you need a static or global variable of a class type, consider initializing a pointer (which will never be freed), from

either your main() function or from pthread_once(). Note that this must be a raw pointer, not a "smart" pointer, since

the smart pointer's destructor will have the order-of-destructor issue that we are trying to avoid.

Classes

Classes are the fundamental unit of code in C++. Naturally, we use them extensively. This section lists the main

dos and don'ts you should follow when writing a class.

Doing Work in Constructors

link ▽

In general, constructors should merely set member variables to their initial values. Any complex initialization should

go in an explicit Init() method.

Definition: It is possible to perform initialization in the body of the constructor.

Pros: Convenience in typing. No need to worry about whether the class has been initialized or not.

Cons: The problems with doing work in constructors are:

 There is no easy way for constructors to signal errors, short of using exceptions (which are forbidden).

 If the work fails, we now have an object whose initialization code failed, so it may be an indeterminate

state.

 If the work calls virtual functions, these calls will not get dispatched to the subclass implementations.

Future modification to your class can quietly introduce this problem even if your class is not currently

subclassed, causing much confusion.

 If someone creates a global variable of this type (which is against the rules, but still), the constructor code

will be called before main(), possibly breaking some implicit assumptions in the constructor code. For

instance, gflags will not yet have been initialized.

Decision: If your object requires non-trivial initialization, consider having an explicit Init() method. In particular,

constructors should not call virtual functions, attempt to raise errors, access potentially uninitialized global

variables, etc.

Default Constructors

link ▽

You must define a default constructor if your class defines member variables and has no other constructors.

Otherwise the compiler will do it for you, badly.

Definition: The default constructor is called when we new a class object with no arguments. It is always called when

calling new[] (for arrays).

Pros: Initializing structures by default, to hold "impossible" values, makes debugging much easier.

Cons: Extra work for you, the code writer.

Decision:

If your class defines member variables and has no other constructors you must define a default constructor (one

that takes no arguments). It should preferably initialize the object in such a way that its internal state is consistent

and valid.

The reason for this is that if you have no other constructors and do not define a default constructor, the compiler

will generate one for you. This compiler generated constructor may not initialize your object sensibly.

If your class inherits from an existing class but you add no new member variables, you are not required to have a

default constructor.

Explicit Constructors

link ▽

Use the C++ keyword explicit for constructors with one argument.

Definition: Normally, if a constructor takes one argument, it can be used as a conversion. For instance, if you define

Foo::Foo(string name) and then pass a string to a function that expects a Foo, the constructor will be called

to convert the string into a Foo and will pass the Foo to your function for you. This can be convenient but is also a

source of trouble when things get converted and new objects created without you meaning them to. Declaring a

constructor explicit prevents it from being invoked implicitly as a conversion.

剩余45页未读，继续阅读

Javapub

粉丝: 0
资源: 4

谷歌C++编程风格指南(英文版)

Google C++ Style Guide_英文版.pdf

Google C++ Style Guide中英文版.rar

Google C++ Style Guide (中文版).pdf

谷歌C++规范 Google C++ Style Guide PDF

Google C++ Style Guide

google c++ style guide

Google C++ Style Guide.zip

Google C++ Style Guide翻译版

Google C++ Style Guide.png

Google C++ Style Guide.pdf

最新资源