Google C++程式設計風格指南（八）：規則之例外

 http://www.kuqin.com/language/20080726/12450.html

 

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

 

• 規則之例外

前面說明的編碼習慣基本是強制性的，但所有優秀的規則都允許例外。

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