Google C + + programming style guide (i)

Background

Most of Google's open source projects are developed using C + +. As every C + + programmer knows, C + + has a lot of powerful language features, but it's a powerful and unavoidable complication that makes code more prone to bugs, harder to read and maintain.

The purpose of this guide is to circumvent its complexities by elaborating how to write and not write in C + + coding. These rules make it easy to manage while allowing code to use the C + + language feature effectively.

Style, also considered as readability, mainly refers to the habit of managing C + + code. Using the term style is a bit of a misnomer because these habits are much more than the source code file format.

One way to make your code easy to manage is to enhance code consistency so that others can read your code, and maintaining a unified programming style means that you can easily infer the meaning of various symbols based on the pattern matching rule. Creating generic, required idioms and patterns makes your code easier to understand, and in some cases changing some programming style may be a good choice, but we should still follow the principle of consistency and try not to.

Another view of this guide is that the C + + feature is bloated. C + + is a huge language that contains a large number of advanced features, and in some cases we restrict or even prohibit the use of certain features to simplify the code and avoid possible problems, as outlined in the guide, and explain why these features are restricted.

Open source projects developed by Google will be governed by this guidance Convention.

Note: This guide is not a C + + tutorial, and we assume that the reader is already familiar with C + +.

Header file

Typically, each. cc file (the source file for C + +) has a corresponding. h file (header file), with some exceptions, such as unit test code and. cc files that contain only main ().

Using header files correctly can make your code significantly more readable, file size, and performance.

The following rules will guide you through the hassle of using header files.

1. #define的保护

All header files should use #define to prevent header files from being multiple inclusions (multiple inclusion), named format when: <project>_<path>_<file>_h_

To ensure uniqueness, the header file name should be based on the full path of the project's source code tree in which it resides. For example, the header file Foo/src/bar/baz.h in Project Foo is protected as follows:

#ifndef Foo_bar_baz_h_

#define Foo_bar_baz_h_

...

#endif//Foo_bar_baz_h_