Google C++编程规范与最佳实践

需积分: 0 166 浏览量更新于2024-06-15 收藏 421KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"Google C++ 开发规范指南旨在管理和优化C++编程的复杂性，确保代码的可读性和可维护性。本指南适用于已经熟悉C++的开发者，它提供了关于头文件、作用域、类、函数以及其他C++特性的详细指导原则。" 以下是Google C++ Style Guide的一些关键点： 1. **头文件**： - **Self-contained Headers**：头文件应自包含，避免引入不必要的依赖。 - **#define Guard**：每个头文件应包含一个预处理器宏定义，防止重复包含。 - **Forward Declarations**：尽可能使用前向声明，减少头文件的依赖。 - **Inline Functions**：内联函数用于小且频繁调用的函数，以减少代码体积。 - **Names and Order of Includes**：遵循特定的包含顺序，比如先包含系统头文件，再包含项目头文件。 2. **Scoping**： - **Namespaces**：使用命名空间减少全局作用域的污染。 - **Unnamed Namespaces and Static Variables**：未命名的命名空间和静态变量用于限制作用域，防止意外的名称冲突。 - **Nonmember, Static Member, and Global Functions**：鼓励使用非成员函数，除非它们与类有特殊的关联。 - **Local Variables**：合理使用局部变量，保持作用域尽可能小。 - **Static and Global Variables**：谨慎使用全局和静态变量，因为它们可能引发复杂的内存问题。 3. **Classes**： - **Doing Work in Constructors**：构造函数用于初始化对象状态，但不应执行大量工作。 - **Implicit Conversions**：避免隐式类型转换，以防止意外的行为。 - **Copyable and Movable Types**：考虑复制和移动语义，确保正确实现拷贝构造函数和赋值运算符。 - **Structs vs. Classes**：通常使用类，除非设计为轻量级数据结构，才考虑使用结构体。 - **Inheritance**：使用继承来表达“is-a”关系，但应谨慎使用多继承。 - **Interfaces**：接口类用于定义纯虚函数，提供一种抽象契约。 - **Operator Overloading**：适度使用运算符重载，保持其自然行为。 - **Access Control**：明智地使用公有、私有和受保护的访问控制，以封装实现细节。 4. **Functions**： - **Parameter Ordering**：参数应按逻辑顺序排列，便于阅读。 - **Write Short Functions**：编写短小精悍的函数，提高可读性。 - **Reference Arguments**：使用引用参数以避免不必要的复制。 - **Function Overloading**：利用函数重载来实现多态，但避免过度使用。 - **Default Arguments**：默认参数简化函数调用，但应谨慎使用。 - **Trailing Return Type Syntax**：使用尾随返回类型以提高清晰度。 5. **其他C++特性**： - **Rvalue References**：用于支持移动语义和右值引用。 - **Friends**：在必要时使用友元，但要谨慎，以保持封装性。 - **Exceptions**：明智地使用异常处理，避免在关键代码路径中抛出异常。 - **Run-Time Type Information (RTTI)**：尽量避免使用RTTI，除非确实需要动态类型检查。 - **Casting**：推荐使用`static_cast`，`dynamic_cast`，`const_cast`和`reinterpret_cast`，以明确转换意图。此外，指南还包括对智能指针的使用、cpplint工具的介绍、其他C++特性如流、预处理器宏、大小端移植性、`auto`关键字、初始化列表、lambda表达式、模板元编程等的指导。遵循Google C++ Style Guide，可以创建更加一致、易于理解和维护的代码，从而提高团队的生产力和软件质量。

资源详情

资源推荐

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

Variables of class type with static storage duration 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 non-local static 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. However, a static POD variable within

function scope may be initialized with the result of a function, since its initialization order is well-defined and does not

occur until control passes through its declaration.

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

another variable that contains a reference to that string.

One way to alleviate the destructor problem is to terminate the program by calling quick_exit() instead of exit().

The difference is that quick_exit() does not invoke destructors and does not invoke any handlers that were registered

by calling atexit(). If you have a handler that needs to run when a program terminates via quick_exit() (flushing

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 register it in both places.)

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

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

Avoid virtual method calls in constructors, and avoid initialization that can fail if you can't signal an error.

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

 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.

 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.

 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, 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.

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).

Implicit Conversions

Do not define implicit conversions. Use the explicit keyword for conversion operators and single-argument

constructors.

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 defined by the language, users can define their own, by adding appropriate

members to the class definition of the source or destination type. An implicit conversion in the source type is defined by a

type conversion operator named after the destination type (e.g. operator bool()). An implicit conversion in the

destination type is defined 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.

 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.

 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 define 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.

Type conversion operators, and constructors that are callable with a single argument, must be marked explicit in the

class definition. 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};).

Copyable and Movable Types

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.

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-defined types, the copy behavior is defined 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 (all copyable types are therefore movable).

std::unique_ptr<int> is an example of a movable but not copyable type. For user-defined types, the move behavior

is defined 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.

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 flexibility in e.g., type composition.

Copy/move constructors and assignment operators are usually easier to define 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 efficient,

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 efficient transfer of resources out of rvalue objects. This allows a plainer coding

style in some cases.

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 specific 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 difficult 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.

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 define a copy or move constructor, define the corresponding assignment operator, and vice-

versa. If your type is copyable, do not define move operations unless they are significantly more efficient 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 defining both of the move operations.

剩余61页未读，继续阅读

Dirac'

粉丝: 57
资源: 3

Google C++编程规范与最佳实践

Google+C+++编程规范.pdf

Google C++ Style Guide.pdf_编程规范_style_C++_

Google-C++编码规范中文版（最新整理PDF版）

main函数 cpp的规范写法

PHP-CPP怎么开发PHP扩展

谷歌c++编码规范链接

Cpp后端开发需要掌握什么技术栈

autosar_rs_cpp14guidelines.pdf

编写可以编译和运行0521.cpp, 0523.cpp 和0525. cpp这3个cpp文件的makefile

unable to activate cppcheck analyzer.

c++中cpp如何调用另一个cpp

set CPPCHECK_PATH="C:\Program Files\Cppcheck\cppcheck.ex

qt中widget.cpp和main.cpp中

cppcheck的使用方法

用C++编译器编写makefile显示规则，目标文件为main，依赖文件为main.cpp、mainwindow.cpp、manger.cpp，其中manger.cpp包含文件menimanage.cpp

c++ 把一个cpp中的参数传到另一个cpp

qt中widget.cpp和main.cpp区别

vscode怎么运行开发机上的main.cpp

protobuf-cpp3.5.1

qt yaml-cpp

最新资源