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<prj_name/public/tools.h>）；

5) 除非万不得已，不然不利用任何不尺度的扩展，如#pragma和__declspec，答允利用__declspec(dllimport)和__declspec(dllexport)，但必需通过DLLIMPORT和DLLEXPORT等宏，以便其他人在共享利用这些代码时容易放弃这些扩展。

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

1) 凡是我们克制利用多重担任，但在利用COM和ATL/WTL类时可以利用多重担任，为了执行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.

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

编程气势气魄指南的利用要点在于提供一个民众的编码类型，所有人可以把精神会合在实现内容而不是表示形式上。我们给出了全局的气势气魄类型，但局部的气势气魄也很重要，假如你在一个文件中新加的代码和原有代码气势气魄相去甚远的话，这就粉碎了文件自己的整体雅观也影响阅读，所以要只管制止。

好了，关于编码气势气魄写的差不多了，代码自己才是更有趣的，恣意享受吧！