GoogleCpp風格指南 9)規則特例 10)結束語

9 規則特例 Exceptions to the Rules

前面說明的編程習慣基本都是強制性的mandatory; 但所有優秀的規則都允許例外, 這裏探討這些特例;

9.1 現有不合規範的代碼 Existing Non-conformant Code

Tip 對於現有不符合conform 既定編程風格的代碼可以網開一面diverge;

當你修改使用其他風格的代碼時, 爲了與代碼原有風格一致可以不使用本指南約定; 如果不放心可以與原代碼作者或現在的負責人員商討, 記住, 一致性包括原有的一致性;


9.2 Windows Code

Tip Windows程序員有自己的編程習慣, 主要源於derived from Windows頭文件和其他Microsoft代碼; 我們希望任何人都可以順利讀懂你的代碼, 所以針對所有平臺的C++編程只給出一個單獨的指南;

如果你習慣使用流行的prevalent  Windows編碼風格, 這裏有必要重申reiterating一下某些你可能會忘記的指南;

- 不要使用匈牙利命名法Hungarian notationli(比如把整型變量命名爲 iNum); 使用Google命名約定; 包括對源文件使用 .cc擴展名;

- Windows定義了很多原生primitive類型的同義詞synonyms; 如 DWORD, HANDLE等; 在調用Windows API時這是完全可以接受甚至鼓勵的; 但還是儘量使用原有的C++類型, 例如使用 const TCHAR* 而不是 LPCTSTR;

- 使用Microsoft Visual C++進行編譯時, 將警告級別設置爲level 3或更高, 並將所有warnings當作error處理;

- 不要使用 #pragma once; 而應該使用Google的頭文件保護規則; 頭文件保護的路徑應該相對於項目根目錄; (譯註, 如 #ifdef SRC_DIR_BAR_H_; 參考 #define保護);

- 除非萬不得已, 不要使用任何非標準的擴展; 如 #pragma __declspec; 允許使用 __declspec(dllimport)  __declspec(dllexport); 但你必須通過宏來使用, 比如 DLLIMPORT DLLEXPORT; 這樣其他人在分享使用這些代碼時很容易就去掉這些擴展;

[Windows需要顯式地導出, Linux默認導出]

在Windows上, 只有很少的一些情況下, 可以偶爾違反規則:

- 通常我們禁止使用多重繼承forbid the use of multiple implementation inheritance, 但在使用COM和ATL/WTL類時可以使用多重繼承; 爲了實現COM或ATL/WTL類/接口; 你可能不得不使用多重實現繼承;

- 雖然代碼中不應該使用異常, 但是在ATL和部分STL(包括Visual C++的STL)中異常被廣泛使用; 使用ATL時, 應定義 _ATL_NO_EXCEPTIONS以禁用異常; 要研究一下是否能夠禁用STL的異常; 如果無法禁用, 啓用編譯器異常也可以; [http://msdn.microsoft.com/zh-cn/library/1deeycx5.aspx http://msdn.microsoft.com/zh-cn/library/d42ws1f6.aspx ] (注意這只是爲了編譯STL, 自己代碼裏仍然不要包含異常處理); 

- 通常爲了利用頭文件預編譯precompiled headers, 每個源文件的開頭都會包含一個名爲 StdAfx.h  precompile.h 的文件[pch.h, 預編譯完成不一定需要inculde]; 爲了使代碼方便與其他項目共享, 避免顯式包含此文件 (precompile.cc); 使用 /FI編譯器選項以自動包含; 

- 資源頭文件通常命名爲 resource.h, 而且只包含宏的那些, 不需要遵守本風格指南; [MFC]


10 結束語 Parting Words

Tip 運用常識和判斷力, 並保持一致; common sense and BE CONSISTENT

編輯代碼時, 花點時間看看項目中的其他代碼, 並熟悉風格; 如果其他代碼中 if語句使用空格; 那麼你也要用; 如果其中的註釋用星號(*)圍成一個盒子狀, 你同樣要這麼做;

風格指南的重點在於提高一個通用的編程規範vocabulary, 這樣大家可以把精力集中在實現內容而不是表現形式上; 我們展示了全局的風格規範, 但局部風格也很重要, 如果你在一個文件中新加的代碼和原有代碼風格想去甚遠drastically, 就破壞discontinuity了文件本身的整體美觀, 影響閱讀節奏rhythm, 所以要儘量避免;

關於編碼風格寫的夠多了, 代碼本身才更有趣, Enjoy it;

Revision 3.133

---End---


Reference -- Guildline

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

http://zh-google-styleguide.readthedocs.org/en/latest/

http://www.yeolar.com/note/2013/08/28/cpp-style-guide/ 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章