谷歌C++编码规范 Google C++ Style Guide.docx

1、谷歌C+编码规范 Google C+ Style GuideGoogle C+ Style GuideRevision 3.180 Benjy WeinbergerCraig SilversteinGregory EitzmannMark MentovaiTashana 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

2、 all summaries with the big arrow button: Toggle all summaries Table of ContentsHeader FilesThe #define Guard Header File Dependencies Inline Functions The -inl.h Files Function Parameter Ordering Names and Order of Includes ScopingNamespaces Nested Classes Nonmember, Static Member, and Global Funct

3、ions Local Variables Static and Global Variables ClassesDoing 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

4、MagicSmart Pointers cpplint Other C+ FeaturesReference 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 Mac

5、ros 0 and NULL sizeof Boost C+0x NamingGeneral Naming Rules File Names Type Names Variable Names Constant Names Function Names Namespace Names Enumerator Names Macro Names Exceptions to Naming Rules CommentsComment Style File Comments Class Comments Function Comments Variable Comments Implementation

6、 Comments Punctuation, Spelling and Grammar TODO Comments Deprecation Comments FormattingLine 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

7、Variable and Array Initialization Preprocessor Directives Class Format Constructor Initializer Lists Namespace Formatting Horizontal Whitespace Vertical Whitespace Exceptions to the RulesExisting Non-conformant Code Windows Code Important NoteDisplaying Hidden Details in this Guidelink This style gu

8、ide 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, theres an expand all at the top of th

9、is document. BackgroundC+ is the main development language used by many of Googles 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 go

10、al of this guide is to manage this complexity by describing in detail the dos and donts 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

11、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 anothers code and quickly und

12、erstand 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 migh

13、t 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 certai

14、n 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 g

15、uide is not a C+ tutorial: we assume that the reader is familiar with the language. Header FilesIn 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 mak

16、e 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. The #define Guardlink All header files should have #define guards to prevent multiple inclusion. The format of the symbol name should be _

17、H_. To guarantee uniqueness, they should be based on the full path in a projects 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 Dependencieslink Dont use an #include

18、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

19、 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

20、 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*

21、 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 stat

22、ic 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) membe

23、rs 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 h

24、ave 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 i

25、s if Foo is used in myfile.cc, its ok to #include (or forward-declare) Foo in myfile.h, instead of myfile.cc. Inline Functionslink 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 ra

26、ther 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 ac

27、tually make programs slower. Depending on a functions 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

28、 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

29、 thumb: its 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 recursi

30、ve 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 Fileslink You may us

31、e 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

32、 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 un