Google C++编码风格指南：提升代码可读性和维护性

需积分: 12 191 浏览量更新于2024-07-18 收藏 556KB PDF 举报

Google C++编码风格指南是一份详细的文档，旨在为Google开源项目的C++程序员提供一套系统的编码规范，以管理和控制C++语言的复杂性，从而提高代码质量、可读性和维护性。该指南分为多个部分，包括： 1. **介绍**：阐述了C++语言的强大功能与其带来的复杂性，以及编写清晰、一致代码在开发中的重要性。 2. **背景**：强调了在面临复杂性时，制定统一的编码风格是必不可少的，它不仅涉及源代码格式，还包括更广泛的编程实践。 3. **头文件管理**：指南可能涵盖了如何组织和引用头文件，以减少依赖混乱和提高代码复用性。 4. **作用域**：介绍了如何正确处理变量的作用域，以避免命名冲突和提升代码的可理解性。 5. **类与对象**：这部分可能讲解了Google对于类设计、继承、封装和多态的偏好，以确保代码结构清晰且易于维护。 6. **Google特色魔法**：可能涉及到Google特定的最佳实践，如模板元编程、宏或特定库的使用，这些可能反映了Google的工程实践。 7. **其他C++特性**：指南可能探讨如何恰当地使用C++11及以上版本的新特性，如RAII（Resource Acquisition Is Initialization）、智能指针等，以提升代码的性能和安全性。 8. **命名约定**：规定了变量、函数、常量和类名的命名规则，以增强代码的一致性和可读性。 9. **注释**：指导如何添加有效的注释，以解释复杂的逻辑和设计决策，使其他开发者能更容易地理解代码。 10. **格式化**：详细描述了代码的布局、缩进、空格和换行等方面的规范，以保持视觉上的整洁。 11. **规则例外**：列出了一些特殊情况下的允许偏离，可能针对特定场景或技术难题，但仍遵循整体原则。 12. **结束语**：总结了指南的目标，强调了遵循编码风格对团队协作和长期项目维护的重要性。这份指南的最新修订版本为3.274，由多位专家和编辑共同完成，包括Benjy Weinberger、Craig Silverstein、Gregory Eitzmann等人。指南还提供了一个Web页面（<http://www.guiquanz.me>），开发者可以在此获取完整的规则和示例。通过遵循这份Google C++编码风格指南，开发者能够写出高效、易读且维护的代码。

// Forbidden -- This pollutes the namespace.

using namespace foo;

You may use a using-declaration anywhere in a .cc file, and in functions, methods or classes in .h files.

// OK in .cc files.

// Must be in a function, method or class in .h files.

using ::foo::bar;

Namespace aliases are allowed anywhere in a .cc file, anywhere inside the named namespace that wraps an entire

.h file, and in functions and methods.

// Shorten access to some commonly used names in .cc files.

namespace fbz = ::foo::bar::baz;

// Shorten access to some commonly used names (in a .h file).

namespace librarian {

// The following alias is available to all files including

// this header (in namespace librarian):

// alias names should therefore be chosen consistently

// within a project.

namespace pd_s = ::pipeline_diagnostics::sidetable;

inline void my_inline_function() {

// namespace alias local to a function (or method).

namespace fbz = ::foo::bar::baz;

...

}

} // namespace librarian

Note that an alias in a .h file is visible to everyone #including that file, so public headers (those available outside a

project) and headers transitively #included by them, should avoid defining aliases, as part of the general goal of

keeping public APIs as small as possible.

Do not use inline namespaces.

Although you may use public nested classes when they are part of an interface, consider a namespace to keep declarations out of the global scope.

Definition:

A class can define another class within it; this is also called a member class.

class Foo {

private:

// Bar is a member class, nested within Foo.

class Bar {

...

};

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

Nested Classes

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.

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.

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.

Nonmember, Static Member, and Global Functions

Local Variables

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

vector<int> v;

v.push_back(1); // Prefer initializing using brace initialization.

v.push_back(2);

vector<int> v = {1, 2}; // Good -- v starts initialized.

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 or global variables of class type are forbidden: they cause hard-to-find bugs due to indeterminate order of construction and destruction. However, such variables are allowed if they are constexpr: they have no dynamic initialization or 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, global and static variables are destroyed when the program terminates, regardless of whether the termination

is by returning from main() or by calling exit() . 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

Static and Global Variables

剩余64页未读，继续阅读

kevin_sdm

粉丝: 0
资源: 2

Google C++编码风格指南：提升代码可读性和维护性

Google C++ Style Guide.zip

Google Coding Style C++

google c++ coding style.png

Google C++ Style Guide(Google C++编程规范）高清PDF

Google C++ Style Guide (English)

Google C++ Style Guide (English) for Kindle 3

Google coding style

C++ Coding Standard

coding

C++ programming

最新资源