Google C ++ Style Guide

Google C ++ Style Guide-Chinese Simplified ¶

Version:	3.133
Original Author:	Benjy weinbergercraig silversteingregory eitzmannmark mentovaitashana landray
Translation:	Yulefoxyospaly
Project homepage:	Google Style Guide Google open-source project Style Guide-Chinese Version

Directory

Contents

• Google C ++ Style Guide-Chinese Version
  • Directory
  • Translator's preface
  • Background

• 1. header file
  • 1.1. # define protection
  • 1.2. header file dependency
  • 1.3. inline functions
  • 1.4.-inL. h file
  • 1.5. Order of function parameters
  • 1.6.# IncludePath and order
  • Yulefox notes
• 2. Scope
  • 2.1. namespace
    • 2.1.1. Anonymous namespace
    • 2.1.2. Named namespace
  • 2.2. Nested classes
  • 2.3. Non-member functions, static member functions, and global functions
  • 2.4. Local Variables
  • 2.5. Static and global variables
  • Yulefox notes
• 3. Class
  • 3.1. Constructor's Responsibilities
  • 3.2. default constructor
  • 3.3. Explicit Constructor
  • 3.4. copy constructors
  • 3.5. struct vs. Class
  • 3.6. Inheritance
  • 3.7. Multi-Inheritance
  • 3.8. Interface
  • 3.9. Operator Overloading
  • 3.10. Access Control
  • 3.11. Declaration Order
  • 3.12. Compile Short Functions
  • Yulefox notes
• 4. Tech from Google
  • 4.1. smart pointer
  • 4.2. cpplint
• 5. Other C ++ features
  • 5.1. Reference parameters
  • 5.2. Function Overloading
  • 5.3. Default Parameters
  • 5.4. variable-length array and alloca ()
  • 5.5. youyuan
  • 5.6. Exception
  • 5.7. runtime type recognition
  • 5.8. type conversion
  • 5.9. Stream
  • 5.10. Pre-auto-increment and auto-Increment
  • 5.11.ConstUse
  • 5.12. Integer
  • 5.13. 64-bit portability
  • 5.14. Preprocessing macros
  • 5.15. 0 and null
  • 5.16. sizeof
  • 5.17. Boost Library
• 6. Naming Conventions
  • 6.1. General naming rules
  • 6.2. File Name
  • 6.3. type naming
  • 6.4. variable naming
  • 6.5. Constant naming
  • 6.6. Function Name
  • 6.7. namespace name
  • 6.8. Enumeration naming
  • 6.9. Macro naming
  • 6.10. Special Cases of naming rules
• 7. Notes
  • 7.1. annotation Style
  • 7.2. File comment
  • 7.3. Class Annotation
  • 7.4. Function comments
  • 7.5. Variable comments
  • 7.6. Implementation notes
  • 7.7. punctuation, spelling, and grammar
  • 7.8. Todo comments
  • Yulefox notes
• 8. Format
  • 8.1. row length
  • 8.2. Non-ASCII characters
  • 8.3. Space or tab
  • 8.4. function declaration and definition
  • 8.5. function call
  • 8.6. Condition statements
  • 8.7. Loop and switch selection statements
  • 8.8. pointer and reference expression
  • 8.9. Boolean expression
  • 8.10. function return value
  • 8.11. Variable and array Initialization
  • 8.12. Preprocessing commands
  • 8.13. Class format
  • 8.14. Initialization list
  • 8.15. namespace formatting
  • 8.16. Horizontal white
  • 8.17. Vertical white
  • Yulefox notes
• 9. Special Rule Cases
  • 9.1. Existing nonstandard code
  • 9.2. Windows code
• 10. Conclusion

Translator's preface

Google often releases some open-source projects, which means it will accept code from other code contributors. however, if the programming style of the Code contributor is different from that of Google, it will cause a lot of trouble for the code reader and other code submissions. google released this programming style so that everyone who submits code can understand Google's programming style.

Original Intention:

The role of a rule is to avoid confusion. however, rules must be authoritative, persuasive, and rational. most of the programming specifications we have seen are either not rigorous, or too simple to elaborate, or have a certain degree of brute force.

Google maintains its rigorous spirit. The 50 thousand Chinese Character guide is widely used and rigorous. the main reason for translating this series of guides is its rigor. rigor means that the value of the guide is not limited to the specifications listed by it, but also the careful trade-offs it makes to list the specifications.

The guide not only lists what you want to do, but also shows you why, when, and how to weigh the pros and cons. it is not necessary for other teams to follow the guidelines. As mentioned above, this guide was developed by Google based on actual conditions and is suitable for open-source projects dominated by Google. other teams can refer to this guide or draw inspiration from it to establish Specifications suitable for their actual situation.

We have gained a lot in the translation process. I hope the Chinese version of this series of guides will help you as well.

We also try our best to keep the translation rigorous, but the bug is inevitable due to the limited level. If you have any comments or suggestions, please contact us.

The Chinese version is the same as the English version.Artistic license/GPLOpen source license.

Chinese version revision history:

• 2009-06 3.133: yulefox 1.0 has been quite well developed, but its specifications have also changed in the last year.

  Yospaly and yulefox work together to extend the Chinese version in the form of a project: Google open-source project Style Guide-Chinese Version project.

  The main change is to synchronize to the latest English version of 3.133, make some errata and improve readability changes, and improve the typographical effect. yospaly is re-renovated, and yulefox will perform subsequent review.

• 2008-07 1.0: This version is also excerpted from yulefox's blog.

Background

C ++ is the main programming language for most open-source projects of Google. as every C ++ programmer knows, C ++ has many powerful features, but this powerful inevitably leads to its complexity and makes the code more prone to bugs, difficult to read and maintain.

The purpose of this Guide is to control the complexity of C ++ by detailing the precautions. These rules ensure that the Code is easy to manage and use the language features of C ++ efficiently.

StyleIt is also called readability, which is the convention that guides C ++ programming. The use of the term "style" is not a good word, because these habits are far more than just the simplicity of source code file formatting.

One of the ways to make code easy to manage is to enhance code consistency. it is very important for any programmer to quickly understand your code. maintaining a unified programming style and complying with conventions means that you can easily deduce the meaning of various identifiers Based on the pattern matching rule. create common and necessary idioms and patterns to make the code easier to understand. in some cases, there may be good reasons to change some programming styles, but we should still follow the consistency principle and try not to do so.

Another point in this guide is the bloated C ++ features. c ++ is a huge language that contains a large number of advanced features. in some cases, we may restrict or even disable certain features. this is done to keep the code fresh and avoid various problems caused by these features. the Guide lists these features and explains why these features are restricted.

All open-source projects led by Google comply with the provisions of this Guide.

Note: This guide is not a C ++ tutorial. We assume that you are familiar with C ++.