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
（完）
留言列表
CSIE (1)