没有合适的资源?快使用搜索试试~ 我知道了~
首页Google C++ 编程规范(精心制作的链接文档-方便查看学习)
资源详情
资源评论
资源推荐
Google C++ Style Guide
Revision 3.180
Benjy Weinberger
Craig Silverstein
Gregory Eitzmann
Mark Mentovai
Tashana Landray
Each style point has a summary for which additional information
is available by toggling the accompanying arrow button that
looks this way: ▽ . You may toggle all summaries with the big
arrow button:
▽ Toggle all summaries
Table of Contents
Header
Files
The #define Guard Header File Dependencies Inline Functions
The -inl.h Files Function Parameter Ordering
Names and Order of Includes
Scoping Namespaces Nested Classes
Nonmember, Static Member, and Global Functions Local Variables
Static and Global Variables
Classes Doing Work in Constructors Default Constructors Explicit Constructors
Copy Constructors Structs vs. Classes Inheritance
Multiple Inheritance Interfaces Operator Overloading Access Control
Declaration Order Write Short Functions
Google-
Specific
Magic
Smart Pointers cpplint
Other C++
Features
Reference Arguments Function Overloading Default Arguments
Variable-Length Arrays and alloca() Friends Exceptions
Run-Time Type Information (RTTI) Casting Streams
Preincrement and Predecrement Use of const Integer Types
64-bit Portability Preprocessor Macros 0 and NULL sizeof Boost
C++0x
Naming General Naming Rules File Names Type Names Variable Names
Constant Names Function Names Namespace Names
Enumerator Names Macro Names Exceptions to Naming Rules
Comments Comment Style File Comments Class Comments Function Comments
Variable Comments Implementation Comments
Punctuation, Spelling and Grammar TODO Comments
Deprecation Comments
Formatting Line Length Non-ASCII Characters Spaces vs. Tabs
Function Declarations and Definitions Function Calls Conditionals
Loops and Switch Statements Pointer and Reference Expressions
Boolean Expressions Return Values Variable and Array Initialization
Preprocessor Directives Class Format Constructor Initializer Lists
link ▽
Namespace Formatting Horizontal Whitespace Vertical Whitespace
Exceptions
to the
Rules
Existing Non-conformant Code Windows Code
Important Note
Displaying Hidden Details in this Guide
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.
Open-source projects developed by Google conform to the requirements in this guide.
Note that this guide is not a C++ tutorial: we assume that the reader is familiar with the language.
Header Files
In general, every .cc file should have an associated .h file. There are some common exceptions,
such as unittests and small .cc files containing just a main() function.
Correct use of header files can make a huge difference to the readability, size and performance of
your code.
The following rules will guide you through the various pitfalls of using header files.
link ▽
link ▽
link ▽
The #define Guard
All header files should have #define guards to prevent multiple inclusion. The format of the
symbol name should be <PROJECT>_<PATH>_<FILE>_H_.
To guarantee uniqueness, they should be based on the full path in a project's source tree. For
example, the file foo/src/bar/baz.h in project foo should have the following guard:
#ifndef FOO_BAR_BAZ_H_
#define FOO_BAR_BAZ_H_
...
#endif // FOO_BAR_BAZ_H_
Header File Dependencies
Don't use an #include when a forward declaration would suffice.
When you include a header file you introduce a dependency that will cause your code to be
recompiled whenever the header file changes. If your header file includes other header files, any
change to those files will cause any code that includes your header to be recompiled. Therefore, we
prefer to minimize includes, particularly includes of header files in other header files.
You can significantly minimize the number of header files you need to include in your own header
files by using forward declarations. For example, if your header file uses the File class in ways
that do not require access to the declaration of the File class, your header file can just forward
declare class File; instead of having to #include "file/base/file.h".
How can we use a class Foo in a header file without access to its definition?
We can declare data members of type Foo* or Foo&.
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 in myfile.h, instead of myfile.cc.
Inline Functions
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:
link ▽
link ▽
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
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
When defining a function, parameter order is: inputs, then outputs.
Parameters to C/C++ functions are either input to the function, output from the function, or both.
Input parameters are usually values or const references, while output and input/output parameters
will be non-const pointers. When ordering function parameters, put all input-only parameters
before any output parameters. In particular, do not add new parameters to the end of the function
just because they are new; place new input-only parameters before the output parameters.
This is not a hard-and-fast rule. Parameters that are both input and output (often classes/structs)
muddy the waters, and, as always, consistency with related functions may require you to bend the
rule.
Names and Order of Includes
link ▽
link ▽
Use standard order for readability and to avoid hidden dependencies: C library, C++ library,
other libraries' .h, your project's .h.
All of a project's header files should be listed as descentants of the project's source directory
without use of UNIX directory shortcuts . (the current directory) or .. (the parent directory). For
example, google-awesome-project/src/base/logging.h should be included as
#include "base/logging.h"
In dir/foo.cc, whose main purpose is to implement or test the stuff in dir2/foo2.h, order your
includes as follows:
1. dir2/foo2.h (preferred location — see details below).
2. C system files.
3. C++ system files.
4. Other libraries' .h files.
5. Your project's .h files.
The preferred ordering reduces hidden dependencies. We want every header file to be compilable
on its own. The easiest way to achieve this is to make sure that every one of them is the first .h file
#included in some .cc.
dir/foo.cc and dir2/foo2.h are often in the same directory (e.g.
base/basictypes_test.cc and base/basictypes.h), but can be in different directories too.
Within each section it is nice to order the includes alphabetically.
For example, the includes in google-awesome-project/src/foo/internal/fooserver.cc
might look like this:
#include "foo/public/fooserver.h" // Preferred location.
#include <sys/types.h>
#include <unistd.h>
#include <hash_map>
#include <vector>
#include "base/basictypes.h"
#include "base/commandlineflags.h"
#include "foo/public/bar.h"
Scoping
Namespaces
Unnamed namespaces in .cc files are encouraged. With named namespaces, choose the
name based on the project, and possibly its path. Do not use a using-directive.
Definition:
Namespaces subdivide the global scope into distinct, named scopes, and so are useful for
preventing name collisions in the global scope.
Pros:
Namespaces provide a (hierarchical) axis of naming, in addition to the (also hierarchical) name axis
provided by classes.
For example, if two different projects have a class Foo in the global scope, these symbols may
collide at compile time or at runtime. If each project places their code in a namespace,
project1::Foo and project2::Foo are now distinct symbols that do not collide.
剩余45页未读,继续阅读
bafghgle
- 粉丝: 28
- 资源: 32
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- zigbee-cluster-library-specification
- JSBSim Reference Manual
- c++校园超市商品信息管理系统课程设计说明书(含源代码) (2).pdf
- 建筑供配电系统相关课件.pptx
- 企业管理规章制度及管理模式.doc
- vb打开摄像头.doc
- 云计算-可信计算中认证协议改进方案.pdf
- [详细完整版]单片机编程4.ppt
- c语言常用算法.pdf
- c++经典程序代码大全.pdf
- 单片机数字时钟资料.doc
- 11项目管理前沿1.0.pptx
- 基于ssm的“魅力”繁峙宣传网站的设计与实现论文.doc
- 智慧交通综合解决方案.pptx
- 建筑防潮设计-PowerPointPresentati.pptx
- SPC统计过程控制程序.pptx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0