规则的例外

上述编码约定是强制性的。然而，像所有好的规则一样，这些规则有时也有例外，我们在此讨论。

现有不符合规范的代码

在处理不符合本风格指南的代码时，你可以偏离规则。

如果你发现自己正在修改按照本指南以外的规范编写的代码，你可能必须偏离这些规则以保持与该代码中的本地约定一致。如果你不确定如何做到这一点，请询问原始作者或当前负责该代码的人。请记住，一致性也包括本地一致性。

Windows 代码

Windows 程序员已经发展出自己的一套编码约定，主要源自 Windows 头文件和其他 Microsoft 代码中的约定。我们希望让任何人都容易理解你的代码，因此我们为所有在任何平台上编写 C++ 的人提供一套统一的指南。

值得重申一些你如果习惯了流行的 Windows 风格可能会忘记的指南：

• 不要使用匈牙利命名法（例如，将整数命名为 iNum）。使用 Google 命名约定，包括源文件使用 .cc 扩展名。
• Windows 为基本类型定义了许多自己的同义词，如 DWORD、HANDLE 等。在调用 Windows API 函数时使用这些类型是完全可以接受的，也是鼓励的。即便如此，尽可能接近底层 C++ 类型。例如，使用 const TCHAR* 而不是 LPCTSTR。
• 使用 Microsoft Visual C++ 编译时，将编译器设置为警告级别 3 或更高，并将所有警告视为错误。
• 不要使用 #pragma once；而是使用标准的 Google include 保护符。include 保护符中的路径应相对于项目树的顶部。
• 事实上，不要使用任何非标准扩展，如 #pragma 和 __declspec，除非你绝对必须。允许使用 __declspec(dllimport) 和 __declspec(dllexport)；但是，你必须通过 DLLIMPORT 和 DLLEXPORT 等宏来使用它们，以便他人在共享代码时可以轻松禁用这些扩展。

然而，我们偶尔需要在 Windows 上打破几条规则：

• 通常我们强烈不鼓励使用多重实现继承；然而，在使用 COM 和某些 ATL/WTL 类时是必需的。你可以使用多重实现继承来实现 COM 或 ATL/WTL 类和接口。
• 虽然你不应该在自己的代码中使用异常，但 ATL 中广泛使用了异常，一些 STL 也是如此，包括 Visual C++ 自带的那个。使用 ATL 时，你应该定义 _ATL_NO_EXCEPTIONS 来禁用异常。你应该调查是否也可以在你的 STL 中禁用异常，但如果不行，在编译器中开启异常是可以的。（请注意，这仅仅是为了让 STL 编译。你自己仍然不应该编写异常处理代码。）
• 使用预编译头文件的通常方式是在每个源文件的顶部包含一个头文件，通常命名为 StdAfx.h 或 precompile.h。为了使你的代码更容易与其他项目共享，避免显式包含此文件（precompile.cc 中除外），并使用 /FI 编译器选项自动包含该文件。
• 资源头文件（通常命名为 resource.h 且仅包含宏）不需要遵循这些风格指南。