Google C++ Code Style
5060 ワード
Header Files
1. Define functions inline only when they are small, say, 10 lines or less
2. When defining a function, parameter order is: inputs, then outputs
3. Use standard order for readability and to avoid hidden dependencies: C library, C++ library, other libraries'
Scoping
1. Do not use a using-directive
2. Place a function's variables in the narrowest scope possible, and initialize variables in the declaration
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
Classes
1. Use the C++ keyword
2. Composition is often more appropriate than inheritance. When using inheritance, make it
3. Do not overload operators except in rare, special circumstances
4. Make data members
1. All parameters passed by reference must be labeled
2. Use overloaded functions (including constructors) only if a reader looking at a call site can get a good idea of what is happening without having to first figure out exactly which overload is being called.
3. We do not allow default function parameters, except in limited situations as explained below. Simulate them with function overloading instead, if appropriate.
4. We do not allow variable-length arrays or
5. We allow use of
6. We do not use C++ exceptions.
7. Avoid using Run Time Type Information (RTTI).
8. Use C++ casts like
9. Use streams only for logging.
10. For simple scalar (non-object) values there is no reason to prefer one form and we allow either. For iterators and other template types, use pre-increment.
11. Use
12. Be very cautious with macros. Prefer inline functions, enums, and
The following usage pattern will avoid many problems with macros; if you use macros, follow it whenever possible: Don't define macros in a Do not just Try not to use macros that expand to unbalanced C++ constructs, or at least document that behavior well. Prefer not using
13. Prefer
Naming
The most important consistency rules are those that govern naming. The style of a name immediately informs us what sort of thing the named entity is: a type, a variable, a function, a constant, a macro, etc., without requiring us to search for the declaration of that entity. The pattern-matching engine in our brains relies a great deal on these naming rules.
Naming rules are pretty arbitrary, but we feel that consistency is more important than individual preferences in this area, so regardless of whether you find them sensible or not, the rules are the rules.
Function names, variable names, and filenames should be descriptive; eschew abbreviation. Types and variables should be nouns, while functions should be "command"verbs.
Comments
Though a pain to write, comments are absolutely vital to keeping our code readable. The following rules describe what you should comment and where. But remember: while comments are very important, the best code is self-documenting. Giving sensible names to types and variables is much better than using obscure names that you must then explain through comments.
When writing your comments, write for your audience: the next contributor who will need to understand your code. Be generous — the next one may be you!
Formatting
Coding style and formatting are pretty arbitrary, but a project is much easier to follow if everyone uses the same style. Individuals may not agree with every aspect of the formatting rules, and some of the rules may take some getting used to, but it is important that all project contributors follow the style rules so that they can all read and understand everyone's code easily.
Minimize use of vertical whitespace.
1. Define functions inline only when they are small, say, 10 lines or less
2. When defining a function, parameter order is: inputs, then outputs
3. Use standard order for readability and to avoid hidden dependencies: C library, C++ library, other libraries'
.h , your project's .h . Scoping
1. Do not use a using-directive
2. Place a function's variables in the narrowest scope possible, and initialize variables in the declaration
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. Classes
1. Use the C++ keyword
explicit for constructors with one argument 2. Composition is often more appropriate than inheritance. When using inheritance, make it
public 3. Do not overload operators except in rare, special circumstances
4. Make data members
private
Other C++ features 1. All parameters passed by reference must be labeled
const .//OK, I doubt that... 2. Use overloaded functions (including constructors) only if a reader looking at a call site can get a good idea of what is happening without having to first figure out exactly which overload is being called.
3. We do not allow default function parameters, except in limited situations as explained below. Simulate them with function overloading instead, if appropriate.
4. We do not allow variable-length arrays or
alloca() . 5. We allow use of
friend classes and functions, within reason. 6. We do not use C++ exceptions.
7. Avoid using Run Time Type Information (RTTI).
8. Use C++ casts like
static_cast<>() . Do not use other cast formats like int y = (int)x; or int y = int(x); . 9. Use streams only for logging.
10. For simple scalar (non-object) values there is no reason to prefer one form and we allow either. For iterators and other template types, use pre-increment.
11. Use
const whenever it makes sense. With C++11, constexpr is a better choice for some uses of const. 12. Be very cautious with macros. Prefer inline functions, enums, and
const variables to macros. The following usage pattern will avoid many problems with macros; if you use macros, follow it whenever possible:
.h file. #define macros right before you use them, and #undef them right after. #undef an existing macro before replacing it with your own; instead, pick a name that's likely to be unique. ## to generate function/class/variable names. 13. Prefer
sizeof(varname) to sizeof(type) . Naming
The most important consistency rules are those that govern naming. The style of a name immediately informs us what sort of thing the named entity is: a type, a variable, a function, a constant, a macro, etc., without requiring us to search for the declaration of that entity. The pattern-matching engine in our brains relies a great deal on these naming rules.
Naming rules are pretty arbitrary, but we feel that consistency is more important than individual preferences in this area, so regardless of whether you find them sensible or not, the rules are the rules.
Function names, variable names, and filenames should be descriptive; eschew abbreviation. Types and variables should be nouns, while functions should be "command"verbs.
Comments
Though a pain to write, comments are absolutely vital to keeping our code readable. The following rules describe what you should comment and where. But remember: while comments are very important, the best code is self-documenting. Giving sensible names to types and variables is much better than using obscure names that you must then explain through comments.
When writing your comments, write for your audience: the next contributor who will need to understand your code. Be generous — the next one may be you!
Formatting
Coding style and formatting are pretty arbitrary, but a project is much easier to follow if everyone uses the same style. Individuals may not agree with every aspect of the formatting rules, and some of the rules may take some getting used to, but it is important that all project contributors follow the style rules so that they can all read and understand everyone's code easily.
Minimize use of vertical whitespace.