Google C++编程风格指南（八）：规则之例外

编程风格指南的使用要点在于提供一个公共的编码规范，所有人可以把精力集中在实现内容而不是表现形式上。我们给出了全局的风格规范，但局部的风格也很重要，如果你在一个文件中新加的代码和原有代码风格相去甚远的话，这就破坏了文件本身的整体美观也影响阅读

• 规则之例外

前面说明的编码习惯基本是强制性的，但所有优秀的规则都允许例外。

1. 现有不统一代码（Existing Non-conformant Code）

对于现有不符合既定编程风格的代码可以网开一面。

当你修改使用其他风格的代码时，为了与代码原有风格保持一致可以不使用本指南约定。如果不放心可以与代码原作者或现在的负责人员商讨，记住，一致性包括原有的一致性。

1. Windows代码（Windows Code）

Windows程序员有自己的编码习惯，主要源于Windows的一些头文件和其他Microsoft代码。我们希望任何人都可以顺利读懂你的代码，所以针对所有平台的C++编码给出一个单独的指导方案。

如果你一直使用Windows编码风格的，这儿有必要重申一下某些你可能会忘记的指南（译者注，我怎么感觉像在被洗脑:D）：

1) 不要使用匈牙利命名法（Hungarian notation，如定义整型变量为iNum），使用Google命名约定，包括对源文件使用.cc扩展名；

2) Windows定义了很多原有内建类型的同义词（译者注，这一点，我也很反感），如DWORD、HANDLE等等，在调用Windows API时这是完全可以接受甚至鼓励的，但还是尽量使用原来的C++类型，例如，使用const TCHAR *而不是LPCTSTR；

3) 使用Microsoft Visual C++进行编译时，将警告级别设置为3或更高，并将所有warnings当作errors处理；

4) 不要使用#pragma once;作为包含保护，使用C++标准包含保护，包含保护的文件路径包含到项目树顶层（译者注，#include）；

5) 除非万不得已，否则不使用任何不标准的扩展，如#pragma和__declspec，允许使用__declspec(dllimport)和__declspec(dllexport)，但必须通过DLLIMPORT和DLLEXPORT等宏，以便其他人在共享使用这些代码时容易放弃这些扩展。

在Windows上，只有很少一些偶尔可以不遵守的规则：

1) 通常我们禁止使用多重继承，但在使用和/类时可以使用多重继承，为了执行COM或ATL/WTL类及其接口时可以使用多重实现继承；

2) 虽然代码中不应使用异常，但在ATL和部分STL（包括Visual C++的STL）中异常被广泛使用，使用ATL时，应定义_ATL_NO_EXCEPTIONS以屏蔽异常，你要研究一下是否也屏蔽掉STL的异常，如果不屏蔽，开启编译器异常也可以，注意这只是为了编译STL，自己仍然不要写含异常处理的代码；

3) 通常每个项目的每个源文件中都包含一个名为StdAfx.h或precompile.h的头文件方便头文件预编译，为了使代码方便与其他项目共享，避免显式包含此文件（precompile.cc除外），使用编译器选项/FI以自动包含；

4) 通常名为resource.h、且只包含宏的资源头文件，不必拘泥于此风格指南。

• 团队合作

参考常识，保持一致。

编辑代码时，花点时间看看项目中的其他代码并确定其风格，如果其他代码if语句中使用空格，那么你也要使用。如果其中的注释用星号（*）围成一个盒子状，你也这样做：

/**********************************
* Some comments are here.
* There may be many lines.
**********************************/

编 程风格指南的使用要点在于提供一个公共的编码规范，所有人可以把精力集中在实现内容而不是表现形式上。我们给出了全局的风格规范，但局部的风格也 很重要，如果你在一个文件中新加的代码和原有代码风格相去甚远的话，这就破坏了文件本身的整体美观也影响阅读，所以要尽量避免。

好了，关于编码风格写的差不多了，代码本身才是更有趣的，尽情享受吧！