Google’s C ++ Style Guide. Part 11

Part 1. Introduction

Part 10. Formatting
Part 11. Exceptions to the rules

This article is a translation of part of Google’s C ++ style guide into Russian.
Original article (fork on github), updated translation

Exceptions to the rule

The coding conventions described above are mandatory. However, as with any rules, sometimes they have exceptions, which we will discuss now.

Existing code that does not match the style

It is permissible to deviate from the rules if you work with code that does not comply with this guide.

If you modify code written in a different style, it is acceptable to deviate from the requirements of this guide and use the “local” style to get consistent code. If in doubt, ask the author of the code (or whoever maintains it). remember, that consistency includes the current coding style as well.

Windows programming

Windows programmers can use a special set of coding conventions based on the style of the header files in Windows and other code from Microsoft. Since we want to make the code understandable for everyone, it is recommended to use a single style guide in C ++, which is the same for all platforms.

Here are a few guidelines that differentiate this guide from the Windows style:

  • Do not use Hungarian notation (for example, naming an integer variable as iNum). Use Google’s naming conventions instead, including the .cc for source files.
  • Windows defines its own synonyms for base types such as DWORD, HANDLE and others. It is clear that it is recommended to use them when calling the Windows API. Anyway, try to define types that are as similar to C ++ as possible. For example use const TCHAR * instead of LPCTSTR
  • When compiling code with Microsoft Visual C ++, set the warning level to 3 or higher. Also set the setting to treat all warnings as errors.
  • Do not use #pragma once… Instead, use the standard re-enablement protection described in the guide from Google. The path components in the name for the security macro must be relative to the project root.
  • In general, don’t use non-standard extensions like #pragma and __declspec (exception for cases of emergency). Usage __declspec (dllimport) and __declspec (dllexport) ok, but you should format them as macros DLLIMPORT and DLLEXPORT: In this case, they can be easily blocked if the code is distributed.

On the other hand, there are rules that can be broken when programming under Windows:

  • It is generally recommended not to use multiple implementation inheritance; however, this is required when using COM and some ATL / WTL classes. In this case (when implementing COM or ATL / WTL), violation of the rule is permissible.
  • Although the use of exceptions in native code is not recommended, they are heavily used in ATL and some STLs (including the Visual C ++ version of the library). When using ATL, you should define _ATL_NO_EXCEPTIONSto deny exceptions. It is advisable to figure out whether it is possible to prohibit exceptions in the STL, however, if this is not feasible, then it is permissible to allow exceptions in the compiler. (Note that this is only allowed for STL compilation. Custom code should not contain exception handlers anyway).
  • The typical way to work with precompiled header files is to include such a file first in each source file, usually named StdAfx.h or precompile.h… To avoid creating problems when distributing your code, it is best to avoid explicitly including such a file (with the exception of Use the compiler option / FI to automatically include such a file.
  • Resource header files (usually resource.h) containing only macros may not follow the guidelines in this guide.


Use common sense and stick to


in style.

If you’re editing someone else’s code, take a few minutes to familiarize yourself with the style of that code. If it uses spaces around if – should be done as well. If the comment is underlined with a line of asterisks, then you should also add such a line to your comment.

The main purpose of the style guide is a single basis, it is a common vocabulary so that you do not get distracted by questions “… how write this … “and focus on what write. The general style rules have been described here, but do not forget about the current style in use. If corrections are made in the existing code that are very different from the original code, it complicates the reading of the code, and it throws it off the rhythm. Try to avoid this.


Image taken from

open source

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *