GoogleC++编程规范pdf整理版

5星 · 超过95%的资源需积分: 10 117 浏览量更新于2023-03-03 评论收藏 862KB PDF 举报

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

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

Important Note

Displaying Hidden Details in this Guide

link ▽

This style guide contains many details that are initially hidden from view. They are marked by

the triangle icon, which you see here on your left. Click it now. You should see "Hooray" appear

below.

Hooray! Now you know you can expand points to get more details. Alternatively, there's an

"expand all" at the top of this document.

Background

C++ is the main development language used by many of Google's open-source projects. As

every C++ programmer knows, the language has many powerful features, but this power

brings with it complexity, which in turn can make code more bug-prone and harder to read and

maintain.

The goal of this guide is to manage this complexity by describing in detail the dos and don'ts of

writing C++ code. These rules exist to keep the code base manageable while still allowing

coders to use C++ language features productively.

Style, also known as readability, is what we call the conventions that govern our C++ code.

The term Style is a bit of a misnomer, since these conventions cover far more than just source

file formatting.

One way in which we keep the code base manageable is by enforcing consistency. It is very

important that any programmer be able to look at another's code and quickly understand it.

Maintaining a uniform style and following conventions means that we can more easily use

"pattern-matching" to infer what various symbols are and what invariants are true about them.

Creating common, required idioms and patterns makes code much easier to understand. In

some cases there might be good arguments for changing certain style rules, but we

nonetheless keep things as they are in order to preserve consistency.

Another issue this guide addresses is that of C++ feature bloat. C++ is a huge language with

many advanced features. In some cases we constrain, or even ban, use of certain features.

We do this to keep code simple and to avoid the various common errors and problems that

these features can cause. This guide lists these features and explains why their use is

restricted.

 We can declare (but not define) functions with arguments, and/or return values, of

type Foo. (One exception is if an argument Foo or const Foo& has a non-explicit,

one-argument constructor, in which case we need the full definition to support

automatic type conversion.)

 We can declare static data members of type Foo. This is because static data

members are defined outside the class definition.

On the other hand, you must include the header file for Foo if your class subclasses Foo or

has a data member of type Foo.

Sometimes it makes sense to have pointer (or better, scoped_ptr) members instead of

object members. However, this complicates code readability and imposes a performance

penalty, so avoid doing this transformation if the only purpose is to minimize includes in header

files.

Of course, .cc files typically do require the definitions of the classes they use, and usually

have to include several header files.

Note: If you use a symbol Foo in your source file, you should bring in a definition

for Foo yourself, either via an #include or via a forward declaration. Do not depend on the

symbol being brought in transitively via headers not directly included. One exception is

if Foo is used in myfile.cc, it's ok to #include (or forward-declare) Foo inmyfile.h, instead

of myfile.cc.

Inline Functions

link ▽

Define functions inline only when they are small, say, 10 lines or less.

Definition:You can declare functions in a way that allows the compiler to expand them inline

rather than calling them through the usual function call mechanism.

Pros:Inlining a function can generate more efficient object code, as long as the inlined function

is small. Feel free to inline accessors and mutators, and other short, performance-critical

functions.

Cons:Overuse of inlining can actually make programs slower. Depending on a function's size,

inlining it can cause the code size to increase or decrease. Inlining a very small accessor

function will usually decrease code size while inlining a very large function can dramatically

increase code size. On modern processors smaller code usually runs faster due to better use

of the instruction cache.

Decision:

A decent rule of thumb is to not inline a function if it is more than 10 lines long. Beware of

destructors, which are often longer than they appear because of implicit member- and

base-destructor calls!

Another useful rule of thumb: it's typically not cost effective to inline functions with loops or

switch statements (unless, in the common case, the loop or switch statement is never

executed).

It is important to know that functions are not always inlined even if they are declared as such;

for example, virtual and recursive functions are not normally inlined. Usually recursive

functions should not be inline. The main reason for making a virtual function inline is to place

its definition in the class, either for convenience or to document its behavior, e.g., for

accessors and mutators.

The -inl.h Files

link ▽

You may use file names with a -inl.h suffix to define complex inline functions when needed.

The definition of an inline function needs to be in a header file, so that the compiler has the

definition available for inlining at the call sites. However, implementation code properly

belongs in .cc files, and we do not like to have much actual code in .h files unless there is a

readability or performance advantage.

If an inline function definition is short, with very little, if any, logic in it, you should put the code

in your .h file. For example, accessors and mutators should certainly be inside a class

definition. More complex inline functions may also be put in a .h file for the convenience of the

implementer and callers, though if this makes the .h file too unwieldy you can instead put that

code in a separate -inl.h file. This separates the implementation from the class definition,

while still allowing the implementation to be included where necessary.

Another use of -inl.h files is for definitions of function templates. This can be used to keep

your template definitions easy to read.

Do not forget that a -inl.h file requires a #define guard just like any other header file.

Function Parameter Ordering

link ▽

When defining a function, parameter order is: inputs, then outputs.

剩余65页未读，继续阅读

liqilovehanxue

2015-03-14

不错，有必要再看看

WebIllusory

粉丝: 54
资源: 32

会员权益专享

Google C++ 编程规范pdf 整理版

评论2

会员权益专享

最新资源

Google C++ 编程规范pdf 整理版

评论2

c++编程规范 pdf

华为c++编程规范pdf

高质量C、C++编程指南.pdf

Google+C+++编程规范

google c++ style guide pdf

C/C++各大编程规范

华为c c++编码规范 pdf

c/c++编程规范 华为标准

谷歌c++编码规范链接

华为技术有限公司c++语言编程规范.pdf 网盘

c++ 模版元编程 pdf

c++ 编程规范 华为

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

华为C++语言编程规范

c++核心编程pdf

Google C++ Style Guide(谷歌C++编码规范 )

华为 c++语言编程规范

c++20高级编程第5版 pdf

会员权益专享

最新资源

c/c++编程规范华为标准

c++ 编程规范华为