2017谷歌C++编程规范详解：88页精华解读

需积分: 10 87 浏览量更新于2024-07-19 收藏 479KB PDF 举报

谷歌C++编程规范英文版是一份由Google于2017年8月发布的详细指南，旨在提供高质量的编码标准和最佳实践，以确保代码的一致性、可读性和性能优化。这份88页的PDF文档涵盖了C++语言的各个方面，从基础结构到高级特性，包括： 1. **Header**：强调了头文件的管理，提倡使用自包含的头文件（self-contained headers），避免循环依赖，以及`#define Guard`的使用，确保预处理器宏定义的安全。 2. **Forward Declarations**：鼓励在不需要完整类型信息时进行函数或类的声明，以减少编译时间。 3. **Inline Functions**：推荐适当使用内联函数，以提高函数调用的效率，但要谨慎考虑过度内联可能带来的代码膨胀问题。 4. **Names and Order of Includes**：指导开发者按照某种顺序（如依赖关系）来组织和包含文件，以提高构建速度和减少编译错误。 5. **Scoping**：深入讨论了命名空间（Namespaces）的作用，如何避免命名冲突，并提到了匿名命名空间和静态变量的使用。 6. **Nonmember, Static Member, and Global Functions**：区分了这些不同类型的函数，强调全局和静态成员函数的限制，以及如何控制其可见性和生命周期。 7. **Local Variables**：提倡尽早声明并初始化局部变量，以提高代码清晰度。 8. **Static and Global Variables**：讲解了静态和全局变量的使用，以及如何管理和控制内存泄漏。 9. **Classes**：详细讨论了类的设计原则，包括构造函数中的工作分配，以及结构体与类的选择。 10. **Inheritance**：阐述了单一继承和多重继承的特点，以及接口设计（Interfaces）的重要性。 11. **Operator Overloading**：指出了合理地重载操作符的要求，以保持代码的易读性。 12. **Access Control**：介绍了访问修饰符（public, private, protected）的应用，强调了封装和信息隐藏的原则。 13. **Declaration Order**：推荐按照一定的顺序声明和定义变量和函数，以提高代码的可读性。 14. **Functions**：强调编写短小、功能明确的函数，避免过长函数，支持引用参数和默认参数的使用。 15. **C++ Specific**：涵盖了一些C++特有的技术，如Rvalue References（移动语义）、Friends、异常处理（Exception Handling）、运行时类型信息（RTTI）、类型转换（Casting）等。 16. **C++ Features**：介绍了C++11及后续版本的新特性，如auto关键字、brace-enclosed initializer lists、lambda expressions、模板元编程等。 17. **Boost**：提到了Boost库的一些最佳实践，特别是std::hash的使用。 18. **std::**：强调了标准库的使用，如std::hash的使用以及非标准扩展的处理。 19. **Preprocessor Macros**：对预处理器宏的使用给出了指导，尤其是0和nullptr/NULL的区别以及sizeof运算符的正确应用。 20. **Nonstandard Extensions**：尽管关注标准，但也讨论了在某些情况下可能需要使用非标准扩展的情况。通过遵循这份谷歌C++编程规范，开发人员可以确保他们的代码不仅符合Google的标准，而且具有高性能、可维护性和良好的扩展性。此外，文档还推荐了Google的代码检查工具`cpplint`，用于自动检查代码风格和潜在问题。这是一份值得深入学习和参考的指南，对于任何C++开发者来说都是一个宝贵的资源。

handlers that were registered by calling atexit(). If you have a handler that

needs to run when a program terminates via quick_exit() (ﬂushing logs,

for example), you can register it using at_quick_exit(). (If you have a

handler that needs to run at both exit() and quick_exit(), you need to

As a result we only allow static variables to contain POD data. This rule

completely disallows std::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 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.

Avoid virtual method calls in constructors, and avoid initialization that can fail if

you can't signal an error.

Deﬁnition:

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

Pros:

No need to worry about whether the class has been initialized or not.

Objects that are fully initialized by constructor call can be const and

may also be easier to use with standard containers or algorithms.

Cons:

If the work calls virtual functions, these calls will not get dispatched to

the subclass implementations. Future modiﬁcation to your class can

quietly introduce this problem even if your class is not currently

subclassed, causing much confusion.

There is no easy way for constructors to signal errors, short of crashing

the program (not always appropriate) or using exceptions (which are

forbidden).

If the work fails, we now have an object whose initialization code failed,

Classes

Doing Work in Constructors

https://google.github.io/styleguide/cppguide.html 2017/8/3 16;13

ᒫ 15 ᶭҁو 88 ᶭ҂

so it may be an unusual state requiring a bool IsValid() state

checking mechanism (or similar) which is easy to forget to call.

You cannot take the address of a constructor, so whatever work is done

in the constructor cannot easily be handed off to, for example, another

thread.

Decision:

Constructors should never call virtual functions. If appropriate for your code ,

terminating the program may be an appropriate error handling response.

Otherwise, consider a factory function or Init() method. Avoid Init()

methods on objects with no other states that affect which public methods may

be called (semi-constructed objects of this form are particularly hard to work

with correctly).

Do not deﬁne implicit conversions. Use the explicit keyword for conversion

operators and single-argument constructors.

Deﬁnition:

Implicit conversions allow an object of one type (called the source type) to be

used where a different type (called the destination type) is expected, such as

when passing an int argument to a function that takes a double parameter.

In addition to the implicit conversions deﬁned by the language, users can

deﬁne their own, by adding appropriate members to the class deﬁnition of the

source or destination type. An implicit conversion in the source type is deﬁned

by a type conversion operator named after the destination type (e.g.

operator bool()). An implicit conversion in the destination type is deﬁned

by a constructor that can take the source type as its only argument (or only

argument with no default value).

The explicit keyword can be applied to a constructor or (since C++11) a

conversion operator, to ensure that it can only be used when the destination

type is explicit at the point of use, e.g. with a cast. This applies not only to

implicit conversions, but to C++11's list initialization syntax:

class Foo {

explicit Foo(int x, double y);

...

};

void Func(Foo f);

Func({42, 3.14}); // Error

This kind of code isn't technically an implicit conversion, but the language

treats it as one as far as explicit is concerned.

Pros:

Implicit Conversions

https://google.github.io/styleguide/cppguide.html 2017/8/3 16;13

ᒫ 16 ᶭҁو 88 ᶭ҂

Implicit conversions can make a type more usable and expressive by

eliminating the need to explicitly name a type when it's obvious.

Implicit conversions can be a simpler alternative to overloading.

List initialization syntax is a concise and expressive way of initializing

objects.

Cons:

Implicit conversions can hide type-mismatch bugs, where the

destination type does not match the user's expectation, or the user is

unaware that any conversion will take place.

Implicit conversions can make code harder to read, particularly in the

presence of overloading, by making it less obvious what code is

actually getting called.

Constructors that take a single argument may accidentally be usable as

implicit type conversions, even if they are not intended to do so.

When a single-argument constructor is not marked explicit, there's

no reliable way to tell whether it's intended to deﬁne an implicit

conversion, or the author simply forgot to mark it.

It's not always clear which type should provide the conversion, and if

they both do, the code becomes ambiguous.

List initialization can suffer from the same problems if the destination

type is implicit, particularly if the list has only a single element.

Decision:

Type conversion operators, and constructors that are callable with a single

argument, must be marked explicit in the class deﬁnition. As an exception,

copy and move constructors should not be explicit, since they do not

perform type conversion. Implicit conversions can sometimes be necessary

and appropriate for types that are designed to transparently wrap other types.

In that case, contact your project leads to request a waiver of this rule.

Constructors that cannot be called with a single argument should usually omit

explicit. Constructors that take a single std::initializer_list

parameter should also omit explicit, in order to support copy-initialization

(e.g. MyType m = {1, 2};).

Support copying and/or moving if these operations are clear and meaningful

for your type. Otherwise, disable the implicitly generated special functions that

perform copies and moves.

Deﬁnition:

A copyable type allows its objects to be initialized or assigned from any other

object of the same type, without changing the value of the source. For user-

deﬁned types, the copy behavior is deﬁned by the copy constructor and the

copy-assignment operator. string is an example of a copyable type.

A movable type is one that can be initialized and assigned from temporaries

Copyable and Movable Types

https://google.github.io/styleguide/cppguide.html 2017/8/3 16;13

ᒫ 17 ᶭҁو 88 ᶭ҂

(all copyable types are therefore movable). std::unique_ptr<int> is an

example of a movable but not copyable type. For user-deﬁned types, the move

behavior is deﬁned by the move constructor and the move-assignment

operator.

The copy/move constructors can be implicitly invoked by the compiler in some

situations, e.g. when passing objects by value.

Pros:

Objects of copyable and movable types can be passed and returned by value,

which makes APIs simpler, safer, and more general. Unlike when passing

objects by pointer or reference, there's no risk of confusion over ownership,

lifetime, mutability, and similar issues, and no need to specify them in the

contract. It also prevents non-local interactions between the client and the

implementation, which makes them easier to understand, maintain, and

optimize by the compiler. Further, such objects can be used with generic APIs

that require pass-by-value, such as most containers, and they allow for

additional ﬂexibility in e.g., type composition.

Copy/move constructors and assignment operators are usually easier to deﬁne

correctly than alternatives like Clone(), CopyFrom() or Swap(), because

they can be generated by the compiler, either implicitly or with = default.

They are concise, and ensure that all data members are copied. Copy and

move constructors are also generally more efﬁcient, because they don't

require heap allocation or separate initialization and assignment steps, and

they're eligible for optimizations such as copy elision.

Move operations allow the implicit and efﬁcient transfer of resources out of

rvalue objects. This allows a plainer coding style in some cases.

Cons:

Some types do not need to be copyable, and providing copy operations for

such types can be confusing, nonsensical, or outright incorrect. Types

representing singleton objects (Registerer), objects tied to a speciﬁc scope

(Cleanup), or closely coupled to object identity (Mutex) cannot be copied

meaningfully. Copy operations for base class types that are to be used

polymorphically are hazardous, because use of them can lead to object slicing.

Defaulted or carelessly-implemented copy operations can be incorrect, and the

resulting bugs can be confusing and difﬁcult to diagnose.

Copy constructors are invoked implicitly, which makes the invocation easy to

miss. This may cause confusion for programmers used to languages where

pass-by-reference is conventional or mandatory. It may also encourage

excessive copying, which can cause performance problems.

Decision:

Provide the copy and move operations if their meaning is clear to a casual

user and the copying/moving does not incur unexpected costs. If you deﬁne a

copy or move constructor, deﬁne the corresponding assignment operator, and

vice-versa. If your type is copyable, do not deﬁne move operations unless they

are signiﬁcantly more efﬁcient than the corresponding copy operations. If your

type is not copyable, but the correctness of a move is obvious to users of the

type, you may make the type move-only by deﬁning both of the move

https://google.github.io/styleguide/cppguide.html 2017/8/3 16;13

ᒫ 18 ᶭҁو 88 ᶭ҂

剩余87页未读，继续阅读

CS_DX

粉丝: 0
资源: 2

2017谷歌C++编程规范详解：88页精华解读

Google C++ 编程规范中文版完整指南

Google C++编程规范中文版

谷歌C++编程规范解析与实践

谷歌C++编程规范英文pdf版

google谷歌c++编程规范

Google C++编程规范PDF版

C++编程规范 Google 中文版 C++编程规范 自建笔记

谷歌C++编程规范，中文版

Google C++ 编程规范

google c++编程规范

最新资源

C++编程规范 Google 中文版 C++编程规范自建笔记