[C++] 程式設計實踐之1: Google的C++代碼風格9：規則特例

9. 規則特例

前面說明的程式設計習慣基本都是強制性的，但所有優秀的規則都允許例外，這裡就是探讨這些特例。

對于現有不符合即定程式設計風格的代碼可以網開一面。

當你修改使用其它風格的代碼時，為了與代碼原有風格保持一緻可以不使用本指南約定。如果不放心可以與代碼原作者或者現在的負責人商讨。記住，一緻性包括原有的一緻性。

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

語句使用空格，那麼你也要使用。如果其中的注釋用星号圍成一個大盒子狀，那麼你同樣要這麼做。

風格指南的重點在于提供一個通用的程式設計規範，這樣大家可以把精力集中在實作内容而不是表現形式上。我們展示了全局的風格規範，但局部風格也很重要，如果你在一個檔案中新加的代碼和原有代碼風格相去甚遠，這就破壞了檔案本身的整體美觀，也影響閱讀，所有要盡量避免。

好了，關于編碼風格寫的夠多了；代碼本身才更有趣，盡情享受吧！