9. 规则特例
前面说明的编程习惯基本都是强制性的，但所有优秀的规则都允许例外，这里就是探讨这些特例。
9.1 现有不合规范的代码
对于现有不符合即定编程风格的代码可以网开一面。
当你修改使用其它风格的代码时，为了与代码原有风格保持一致可以不使用本指南约定。如果不放心可以与代码原作者或者现在的负责人商讨。记住，一致性包括原有的一致性。
9.2 Windows代码
Windows程序员有自己的编程习惯，主要源于Windows头文件和其它Microsoft代码。我们希望任何人都可以顺利读懂你的代码，所以针对所有平台的C++编程只给出一个单独的指南。
如果你习惯使用Windows编程风格，这儿有必要重申一下某些你可能会忘记的指南：
- 不要使用匈牙利命名法（比如把整型变量命名成iNum），使用Google命名约定，包括对源文件使用.cc扩展名。
- Windows定义了很多原生类型的同义词，例如DWORD,HANDLE等等，在调用Windows API时，这是完全可以接受甚至鼓励的，但还是尽量使用原有的C++类型，例如使用
const TCHAR *而不是LPCTSTR。 - 使用Microsoft Visual C++进行编译时，将警告级别设置为3或者更高，并将所有warnings当做errors来处理。
- 不要使用
#pragma once；而应使用Google的头文件保护规则。头文件保护的路径应该相对于项目根目录。 - 除非万不得已，不要使用任何非标准的扩展，如
#pragma和__declspec. 允许使用__declspec(dllimport)和__declspec(dllexport); 但你必须通过宏来使用, 比如DLLIMPORT和DLLEXPORT, 这样其他人在分享使用这些代码时很容易就去掉这些扩展。
在Windows上，只有很少的一些情况下，我们可以偶尔违反规则：
- 通常我们禁止使用多重继承，但在使用COM和ATL/WTL类时，可以使用多重继承。为了实现COM或者ATL/WTL类/接口，你可能不得不使用多重实现继承。
- 虽然代码中不应该使用异常，但是在ATL和部分STL（包括Visual C++的STL）中异常被广泛使用。使用ATL时，应定义
_ATL_NO_EXCEPTIONS以禁用异常。你要研究一下是否能够禁用STL的异常。如果无法禁用，弃用编译器异常也可以。（注意这只是为了编译STL，自己代码里仍然不要含异常处理） - 通常为了利用头文件预编译，每个源文件的开头都会包含一个名为
stdAfx.h或者precompile.h的文件。为了使代码方便与其他项目共享，避免显式包含此文件（precompile.cc），使用/FI编译器选项以自动包含。 - 资源头文件通常命名为
resource.h，且只包含宏的，不需要遵守本风格指南。
结束语
运用常识和判断力，并保持一致，因为代码风格也是一种谨慎的权衡过程。
编辑代码时，花点时间看看项目中其它代码，并熟悉其风格。如果其它代码中if语句使用空格，那么你也要使用。如果其中的注释用星号围成一个大盒子状，那么你同样要这么做。
风格指南的重点在于提供一个通用的编程规范，这样大家可以把精力集中在实现内容而不是表现形式上。我们展示了全局的风格规范，但局部风格也很重要，如果你在一个文件中新加的代码和原有代码风格相去甚远，这就破坏了文件本身的整体美观，也影响阅读，所有要尽量避免。
好了，关于编码风格写的够多了；代码本身才更有趣，尽情享受吧！