Amin's Note

Google C++編程風格指南（八）：規則之例外
作者：Google　來源：C++博客　 酷勤網收集　2008-07-26
摘要
酷勤網
　　編程風格指南的使用要點在於提供一個公共的編碼規範，所有人可以把精力集中在實現內容而不是表現形式上。我們給出了全局的風格規範，但局部的風格也很重要，如果你在一個文件中新加的代碼和原有代碼風格相去甚遠的話，這就破壞了文件本身的整體美觀也影響閱讀
系列文章索引：《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.
 **********************************/
 
 

編程風格指南的使用要點在於提供一個公共的編碼規範，所有人可以把精力集中在實現內容而不是表現形式上。我們給出了全局的風格規範，但局部的風格也很重要，如果你在一個文件中新加的代碼和原有代碼風格相去甚遠的話，這就破壞了文件本身的整體美觀也影響閱讀，所以要儘量避免。

好了，關於編碼風格寫的差不多了，代碼本身才是更有趣的，盡情享受吧！

Benjy Weinberger
Craig Silverstein
Gregory Eitzmann
Mark Mentovai
Tashana Landray

（完）

來自：http://www.cppblog.com/Fox/archive/2008/07/23/56933.html