天天看點

[C++] 程式設計實踐之1: Google的C++代碼風格9:規則特例

9. 規則特例

前面說明的程式設計習慣基本都是強制性的,但所有優秀的規則都允許例外,這裡就是探讨這些特例。

9.1 現有不合規範的代碼

對于現有不符合即定程式設計風格的代碼可以網開一面。

當你修改使用其它風格的代碼時,為了與代碼原有風格保持一緻可以不使用本指南約定。如果不放心可以與代碼原作者或者現在的負責人商讨。記住,一緻性包括原有的一緻性。

9.2 Windows代碼

Windows程式員有自己的程式設計習慣,主要源于Windows頭檔案和其它Microsoft代碼。我們希望任何人都可以順利讀懂你的代碼,是以針對所有平台的C++程式設計隻給出一個單獨的指南。

如果你習慣使用Windows程式設計風格,這兒有必要重申一下某些你可能會忘記的指南:

  • 不要使用匈牙利命名法(比如把整型變量命名成iNum),使用Google命名約定,包括對源檔案使用.cc擴充名。
  • Windows定義了很多原生類型的同義詞,例如DWORD,HANDLE等等,在調用Windows API時,這是完全可以接受甚至鼓勵的,但還是盡量使用原有的C++類型,例如使用

    const TCHAR *

    而不是

    LPCTSTR

  • 使用Microsoft Visual C++進行編譯時,将警告級别設定為3或者更高,并将所有warnings當做errors來處理。
  • 不要使用

    #pragma once

    ;而應使用Google的頭檔案保護規則。頭檔案保護的路徑應該相對于項目根目錄。
  • 除非萬不得已,不要使用任何非标準的擴充,如

    #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

    ,且隻包含宏的,不需要遵守本風格指南。

結束語

運用常識和判斷力,并保持一緻,因為代碼風格也是一種謹慎的權衡過程。

編輯代碼時,花點時間看看項目中其它代碼,并熟悉其風格。如果其它代碼中

if

語句使用空格,那麼你也要使用。如果其中的注釋用星号圍成一個大盒子狀,那麼你同樣要這麼做。

風格指南的重點在于提供一個通用的程式設計規範,這樣大家可以把精力集中在實作内容而不是表現形式上。我們展示了全局的風格規範,但局部風格也很重要,如果你在一個檔案中新加的代碼和原有代碼風格相去甚遠,這就破壞了檔案本身的整體美觀,也影響閱讀,所有要盡量避免。

好了,關于編碼風格寫的夠多了;代碼本身才更有趣,盡情享受吧!

繼續閱讀