The philosophy of Google C + + Style Guide

Google C + + Style Guide is not an encyclopedia, nor is it a C + + usage guideline, but it describes the coding guidelines for Google and its open source projects, does not seek to be comprehensive and absolutely correct, and many people doubt some of its rules. But as one of the most influential coding specifications, it has a lot of content worth studying.

The following is mainly from GSG, director of Titus Winters in the Cppcon 2014 speech.

The purpose of developing Google C + + Style Guide

Guide development to do the right thing, but not easy to make mistakes.

The philosophical summary focuses on the reader rather than the author

(Optimize for the reader, not the writer.)
From the standpoint of maintaining code size and teamwork, Google C + + Style Guide is more biased towards the reader's experience than the author of the Code. The reason is that code is much more expensive to read and understand than to encode.

The rules of Moderation

(Rules should pull their weight.)
There is no rule in law, so it will not list all the things that cannot be done. For what is not mentioned, a big rule is followed: "Low profile (Don t be clever.)". (Another way of doing this is not to be silly (don ' t be stupid). )

Standards are important, but not superstitious.

(Value the standard, but don ' t idolize.)
The standard is very important to work, but it does not mean that it is omnipotent. Cppreference.com or StackOverflow can be used to follow up on standard changes, as well as related discussions, which will help to understand standards and use standards.

Maintain consistency

(Be consistent.)
This is one of the most critical. Maintaining consistency helps to break down work and better collaborate, including automation, to reduce unnecessary controversy. The rules that contribute to consistency in GSG include:
* Name of Include Guard
* Parameter order (first input, then output)
* Name space
* Declaration order (class first public, after private, first method, then member variable)
* Naming rules
* Formatting (this kind of thing or hand it to the tool)

Avoid ambiguity and error in a clear, unambiguous way

(If something unusual is happening, leave explicit evidence for the reader)
The core is to write the code in a clear way. Like what:
* A constant reference represents an output parameter, and a pointer representation is modified by a function.
* Override and final modify the member function.
* The name of the Interface class, the Client class, and so on use the corresponding suffix (interface,client). Again
* The overloads of the functions are not explicitly defined using different function names.
* variable parameters, as well as default function parameters, can cause problems in the user's understanding, and may be used incorrectly.
* Using exception Handling (Exception) is not as clear as error handling (err handling).

Avoid risk-controlled implementations, or Kit Kat, because it is too difficult to maintain.

(Avoid constructs that is dangerous or suprising, Avoid Tricky and Hard-to-maintain constructs)
Here are two articles, one of which is risky, or sudden will give a surprise to the way it is implemented:
* Complex static and global objects can cause problems when exiting.
* Use Override and final to avoid incorrect use.
* Using exceptions often transfers errors and is very dangerous.

The other is that some obscure technology will bring about the pressure of maintenance. Like what:
* Do not use macros (complex, unclear)
* Template class Meta programming (complex)
* Non-communal inheritance (may cause unexpected surprises)
* Multiple inheritance (difficult to maintain)

Do not pollute the global namespace

(Avoid polluting the global namespace)
Because the code is too large, there is a high likelihood of conflicts in the global namespace if there is no control. So one important rule is to limit the use of global life space. is also the idea of divide and conquer. The point is:
* Put the code in the namespace.
* Do not place the using in the global namespace in the header file. It spreads as the reference depends.
* the. cc file is less important, but it is still recommended that you put the static variable in the anonymous namespace, and do not use the using namespace to refer to other namespaces.

Concessions to tuning and practicality when necessary

(Concede to optimization and practicalities when necessary)
There are some rules that recommend a better practice. Like what:
* Pre-declaration (optimized compilation time)
* Inline function (limited to smaller functions)
* Recommended use of pre-increment (++i, especially iterators)

About the controversial rules

Titus through the two most controversial rules on how to use the above rules to reach the current conclusions. The two most controversial rules are:
* cannot have an input parameter with very much reference (no Non-const reference as function arguments)
* Not using exceptions (no use of exceptions)

I'm only here to show the rules on which the first rule is based:
* Consistency (consistent with many code implementations)
* Clear, clear, easy to troubleshoot (there are no unexpected changes, or even compile time to prevent problems)
* Risk and unexpected surprises
The life cycle issues of the reference. The reason is that developers are more sensitive to the life cycle of pointers, but the life cycle management of references is easier to overlook.

The point is to know why you are defining the rules, when to apply it, and how to modify it in the future.

The philosophy of Google C + + Style Guide