Google C + + programming style Guide (eight): Exceptions to the rules

The key to the use of the programming style guide is to provide a common coding specification where everyone can focus on implementing content rather than presentation. We give the overall style specification, but the local style is also very important, if you in a file the new code and the original code style is far from the words, this destroys the document itself the overall beauty also affects the reading

Exceptions to the Rules

The coding habits described earlier are basically mandatory, but all good rules allow exceptions.

1. Existing Existing codes (non-conformant code)

For existing code that does not conform to the established programming style, it can be spared.

When you modify code that uses other styles, you may not use this guidance convention in order to be consistent with the original style of the code. If you are not comfortable with the original code or the current responsible person to discuss, remember, consistency includes the original consistency.

1. Windows codes (Windows code)

Windows programmers have their own coding habits, mainly from some of the header files of Windows and other Microsoft code. We want anyone to be able to read your code smoothly, so a separate guideline is given for C + + coding on all platforms.

If you've been using Windows coding style, here's the need to restate some of the guides you might forget (translator, how I feel like brainwashed: D):

1 do not use the Hungarian nomenclature (Hungarian notation, such as the definition of integer variables as inum), using the Google naming convention, including the use of the source file. cc extension;

2 windows defines many synonyms for the original built-in type (translator, which I also resent), such as DWORD, handle, and so on, which is completely acceptable and even encouraged when calling the Windows API, but still try to use the original C + + type, for example, using the const TCHAR * rather than LPCTSTR;

3 when compiling with Microsoft Visual C + +, set the warning level to 3 or higher, and treat all warnings as errors;

(4) Do not use #pragma once; as include protection, use the C + + standard to include protection, including protected file paths to the top level of the project tree (translator, #include <prj_name/public/tools.h>);

5. No non-standard extensions, such as #pragma and __declspec, are permitted to use __declspec (dllimport) and __declspec (dllexport) unless absolutely necessary, However, you must pass macros such as DllImport and dllexport so that others can easily discard these extensions when sharing the code.

On Windows, there are only a few rules that you can occasionally not follow:

1) We generally prohibit multiple inheritance, but you can use multiple inheritance when using COM and ATL/WTL classes, and you can use multiple implementation inheritance in order to execute COM or ATL/WTL classes and their interfaces;

2 Although the code should not use exceptions, but in the ATL and partial STL (including Visual C + + STL) is widely used in the use of ATL, you should define _atl_no_exceptions to mask the exception, you have to study whether or not to shield the STL exception, if not blocked, Turn on compiler exception can also, note that this is only to compile STL, I still do not write with exception handling code;

3 usually each source file in each project contains a header file called StdAfx.h or precompile.h to precompile the header file, in order to make the code easy to share with other projects, avoid explicitly including this file (except for precompile.cc), use compiler Options/ fi to automatically include;

4 A resource header file, usually named Resource.h, that contains only macros, and does not have to adhere to this style guide.

Team work

Consult common sense and keep in line.

When editing the code, take a moment to look at the other code in the project and determine its style, if you use a space in another code if statement, you should use it as well. If the comment is enclosed in a box like an asterisk (*), you do the same:

/**********************************

* Some comments are here.

* There May is many lines.

**********************************/

The key to the use of the programming style guide is to provide a common coding specification where everyone can focus on implementing content rather than presentation. We give the overall style of the specification, but the local style is also very important, if you in a file in the new code and the original code style is far from the words, which destroys the overall beauty of the file itself also affect reading, so try to avoid.

Well, about the coding style written almost, the code itself is more interesting, enjoy it!