谷歌C++编码规范.docx

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

2、ig arrow button:Toggle all summariesTable of ContentsHeader FilesThe #define GuardHeader File DependenciesInline FunctionsThe -inl.h FilesFunction Parameter OrderingNames and Order of IncludesScopingNamespacesNested ClassesNonmember, Static Member, and Global FunctionsLocal VariablesStatic and Globa

3、l VariablesClassesDoing Work in ConstructorsDefault ConstructorsExplicit ConstructorsCopy ConstructorsStructs vs. ClassesInheritanceMultiple InheritanceInterfacesOperator OverloadingAccess ControlDeclaration OrderWrite Short FunctionsGoogle-Specific MagicSmart PointerscpplintOther C+ FeaturesReferen

4、ce ArgumentsFunction OverloadingDefault ArgumentsVariable-Length Arrays and alloca()FriendsExceptionsRun-Time Type Information (RTTI)CastingStreamsPreincrement and PredecrementUse of constInteger Types64-bit PortabilityPreprocessor Macros0 and NULLsizeofBoostC+0xNamingGeneral Naming RulesFile NamesT

5、ype NamesVariable NamesConstant NamesFunction NamesNamespace NamesEnumerator NamesMacro NamesExceptions to Naming RulesCommentsComment StyleFile CommentsClass CommentsFunction CommentsVariable CommentsImplementation CommentsPunctuation, Spelling and GrammarTODO CommentsDeprecation CommentsFormatting

6、Line LengthNon-ASCII CharactersSpaces vs. TabsFunction Declarations and DefinitionsFunction CallsConditionalsLoops and Switch StatementsPointer and Reference ExpressionsBoolean ExpressionsReturn ValuesVariable and Array InitializationPreprocessor DirectivesClass FormatConstructor Initializer ListsNa

7、mespace FormattingHorizontal WhitespaceVertical WhitespaceExceptions to the RulesExisting Non-conformant CodeWindows CodeImportant NoteDisplaying Hidden Details in this GuidelinkThis style guide contains many details that are initially hidden from view. They are marked by the triangle icon, which yo

8、u 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 this document.BackgroundC+ is the main development language used by many of Googles open-source projects. As eve

9、ry 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 donts of writing C+ code. Thes

10、e 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 sourc

11、e file formatting.One way in which we keep the code base manageable is by enforcingconsistency. It is very important that any programmer be able to look at anothers code and quickly understand it. Maintaining a uniform style and following conventions means that we can more easily use pattern-matchin

12、g 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 preser

13、ve 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 c

14、an 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 FilesIn general, every.ccfil

15、e should have an associated.hfile. There are some common exceptions, such as unittests and small.ccfiles containing just amain()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

16、 pitfalls of using header files.The #define GuardlinkAll header files should have#defineguards to prevent multiple inclusion. The format of the symbol name should be_H_.To guarantee uniqueness, they should be based on the full path in a projects source tree. For example, the filefoo/src/bar/baz.hin

17、projectfooshould have the following guard:#ifndef FOO_BAR_BAZ_H_#define FOO_BAR_BAZ_H_.#endif / FOO_BAR_BAZ_H_Header File DependencieslinkDont use an#includewhen a forward declaration would suffice.When you include a header file you introduce a dependency that will cause your code to be recompiled w

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

19、imize 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 theFileclass in ways that do not require access to the declaration of theFileclass, your header file can just forward declareclass File;instead of having

20、 to#include file/base/file.h.How can we use a classFooin a header file without access to its definition? We can declare data members of typeFoo*orFoo&. We can declare (but not define) functions with arguments, and/or return values, of typeFoo. (One exception is if an argumentFooorconst Foo&has a non

21、-explicit, one-argument constructor, in which case we need the full definition to support automatic type conversion.) We can declare static data members of typeFoo. This is because static data members are defined outside the class definition.On the other hand, you must include the header file forFoo

22、if your class subclassesFooor has a data member of typeFoo.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 min

23、imize includes in header files.Of course,.ccfiles typically do require the definitions of the classes they use, and usually have to include several header files.Note:If you use a symbolFooin your source file, you should bring in a definition forFooyourself, either via an #include or via a forward de

24、claration. Do not depend on the symbol being brought in transitively via headers not directly included. One exception is ifFoois used inmyfile.cc, its ok to #include (or forward-declare)Fooinmyfile.h, instead ofmyfile.cc.Inline FunctionslinkDefine functions inline only when they are small, say, 10 l

25、ines 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

26、 accessors and mutators, and other short, performance-critical functions.Cons:Overuse of inlining can actually 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 whi

27、le 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

28、 longer than they appear because of implicit member- and base-destructor calls!Another useful rule of 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

29、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 conven

30、ience or to document its behavior, e.g., for accessors and mutators.The -inl.h FileslinkYou may use file names with a-inl.hsuffix 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 in

31、lining at the call sites. However, implementation code properly belongs in.ccfiles, and we do not like to have much actual code in.hfiles 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 i

32、n your.hfile. For example, accessors and mutators should certainly be inside a class definition. More complex inline functions may also be put in a.hfile for the convenience of the implementer and callers, though if this makes the.hfile too unwieldy you can instead put that code in a separate-inl.hfile. This separates the impleme