前面說明的編程習慣基本都是強制性的. 但所有優秀的規則都允許例外, 這里就是探討這些特例. ## 9.1. 現有不合規范的代碼 > Tip > 對于現有不符合既定編程風格的代碼可以網開一面. 當你修改使用其他風格的代碼時, 為了與代碼原有風格保持一致可以不使用本指南約定. 如果不放心可以與代碼原作者或現在的負責人員商討, 記住, _一致性_ 包括原有的一致性. ## 9.2. Windows 代碼 > Tip > Windows 程序員有自己的編程習慣, 主要源于 Windows 頭文件和其它 Microsoft 代碼. 我們希望任何人都可以順利讀懂你的代碼, 所以針對所有平臺的 C++ 編程只給出一個單獨的指南. 如果你習慣使用 Windows 編碼風格, 這兒有必要重申一下某些你可能會忘記的指南: > > - 不要使用匈牙利命名法 (比如把整型變量命名成 `iNum`). 使用 Google 命名約定, 包括對源文件使用 `.cc` 擴展名. > - Windows 定義了很多原生類型的同義詞 (YuleFox 注: 這一點, 我也很反感), 如 `DWORD`, `HANDLE` 等等. 在調用 Windows API 時這是完全可以接受甚至鼓勵的. 但還是盡量使用原有的 C++ 類型, 例如, 使用 `const TCHAR *` 而不是 `LPCTSTR`. > - 使用 Microsoft Visual C++ 進行編譯時, 將警告級別設置為 3 或更高, 并將所有 warnings 當作 errors 處理. > - 不要使用 `#pragma once`; 而應該使用 Google 的頭文件保護規則. 頭文件保護的路徑應該相對于項目根目錄 (yospaly 注: 如 `#ifndef SRC_DIR_BAR_H_`, 參考 [#define 保護](#) 一節). > - 除非萬不得已, 不要使用任何非標準的擴展, 如 `#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`, 且只包含宏的, 不需要遵守本風格指南.