C/C++ 名正則言順

本系列文章由 @yhl_leo 出品，轉載請注明出處。

文章連結： http://blog.csdn.net/yhl_leo/article/details/50532701

名稱所表達的含義極其豐富，你也許并不生活在對它們的恐懼中，不過絕不要低估名稱的力量。

名稱的重要性無可估量，作為程式員，我們在對各種構造進行命名時，将行使這項重大的權力。一個命名糟糕的實體，不僅很不友善，而且會産生誤導，甚至非常危險。

一個對象名應該清晰地描述這個對象。

那麼究竟應該如何進行命名呢？為對象命名的方式取決于你所遵循的任何編碼标準。不過，雖然标準可能要求适用某種命名約定，但是并不會具體到足以指導如何為程式的每個部分都恰當地命名。

為了恰當地命名，在為每個對象相出名稱之前，必須準确了解這個對象是什麼！如果你都不知道你所命名對象是什麼，它的用途和存在的理由也不清楚，那麼你怎麼能夠賦予它一個有意義的名稱呢？那麼這樣命名得到的實體，絕對是一個命名糟糕的實體。

好的對象名稱往往具有以下四個品質：

• 技術上正确
• 符合語言習慣
• 描述性
• 恰當

下面我們逐一進行分析。

技術上正确

現代程式設計語言對于如何命名都規定了一些準則。以C/C++為例，最基礎的四條原則是：

• 變量名隻能是字母（

  A-Z

  ,

  a-z

  ）和數字（

  0-9

  ）或下劃線

  _

  組成；
• 第一個字母必須是字母或者下劃線；
• 不能使用C/C++關鍵字來命名變量，以免沖突；
• 變量名區分大小寫。

這裡需要補充的是，在前兩條原則下，命名對象可以是以下四種組合方式：純字母（

myName

），或字母與數字的組合（

myName1

,

m2n

），或字母與下劃線的組合（

_myName

,

myName_

,

_myName_

, …），或下劃線與數字的組合（

_1

,

_1_

, …）。

還有一些其他技術限制，例如C/C++标準中預留了一些特定的名稱：你不應該使用任何以

str

作為開頭後面跟一個小寫字母或者以下劃線開頭的全局辨別符，以及任何名為

std

的命名空間中的辨別符。知道這些限制，對于我們編寫魯棒和正确的代碼非常重要。

符合語言習慣

僅僅因為一種語言允許某個特定的字元組合，并不能表示這個組合就是一個好的名稱。清晰明了的名稱，應該遵循讀者所期望的約定，即各種語言習慣。某些語言具有一個公共命名約定，如龐大的Java庫建立了一個不能忽視的先前技術（prior art），而C/C++等語言則沒有這樣一個通用命名約定。

雖然沒有通用的命名約定，但是有些被業内廣泛接受并認可的規則或約定，例如匈牙利命名法，Google C++程式設計命名約定，華為 C程式設計命名約定等，都是值得參考的

描述性

顯而易見，名稱必須是描述性的。這也是使用名稱的原因，即用來描述某個事物。然而我們通常會見到一些令人迷惑的辨別符，其含義與其描述的對象并不相符，甚至相悖。

即使是使用準确的名稱也會有局限性。雖然說不要望文生義，但人們還是通常堅持他們對于一個概念最初的了解。是以，通過謹慎地命名來表達正确的第一印象非常重要。那麼，就有必要從一個外行讀者的角度來選擇名稱，而不是從一個内行的角度來選擇。

有時，找到一個恰當的描述非常困難。如果你無法想出合适恰當的名稱，那麼你也許就要改變你的設計了。這往往是什麼地方不對勁的征兆。

恰當

首先，是長度。雖然限制很多程式設計語言對于辨別符的長度已不再有任何明顯的限制了，但是這并不代表我們可以為了解釋清楚對象的含義，而對其名稱長度不加限制，随意設定。而要建立清晰明了，描述性的名稱，那麼就必須适用自然語言的詞語。對于這些詞語，程式員們都有一種内在的簡寫和縮短它們的欲望，但這有時也會造成令人困惑的雜亂名稱。是以，過度備援或縮減都是不可取的，例如适用

a

來代替

apple_count

顯然不妥，但是使用

apple_count_of_my_apple_funtion

就顯得非常傻。

進行命名時，重點在于清晰而非簡潔。

其次，是格調。就像粗魯的笑話在葬禮上非常不合時宜一樣，欠考慮的名稱也會破壞代碼的職業性。有這麼嚴重嗎？是的。無聊的名稱會使讀者懷疑代碼作者的能力。

應該記住，避免使用一些類似

blah

或

wibble

不嚴肅的名稱，或者

foo

和

bar

等古怪的名稱。它們很容易悄悄混入代碼，雖然一開始人們會覺得挺有趣，但是以後會造成很多混亂。顯而易見的是，職業化就意味着在命名時不要使用語氣助詞。

始終在第一次就給對象起好名字。

<script type="math/tex" id="MathJax-Element-8"> </script>

附上一些相關的内容：

• 匈牙利命名法：是一種有争議的命名約定，他将關于變量或函數的類型資訊編入它們的名稱，認為這樣會使代碼更易于閱讀和維護。這種命名法最初是在20世紀80年代在Microsoft公司中出現，并在該公司的Win32 API和MFC中得到廣泛使用，這也是這種命名法流行的主要原因。之是以被稱為“匈牙利命名法”，是因為它的創始人是以為匈牙利程式員，Charles Simonyi。此外，變量名看起來好像是使用匈牙利語書寫的，也是其得名的原因。
• 大寫字母約定：大多是語言禁止我們在辨別符中使用空白和标點，是以我們要采用一種約定來連接配接多個詞語。這些大寫字母的約定就像沒完沒了的“編輯器聖戰”一樣，使許多程式員互相拳腳相加。在現代的代碼中你會看到很多常用的方法：

  • camelCase

    ： 其在Jave語言庫以及許多C++代碼庫中得到廣泛應用。這種方法得名于其大寫字母的布局很像駱駝的駝峰，并且可能是在20世紀70年代早期在Smalltalk中第一次使用的。

  • ProperCase

    ：這種方法與

    camelCase

    很接近，唯一的差別是其第一個字母也是大寫的。有時這種方法有時也被成為

    PascalCase

    。這兩種約定常常一起使用。例如Java語言的類名以

    ProperCase

    方式書寫，而成員名則以

    camelCase

    方式書寫。Windows API和.NET使用的是

    ProperCase

    。

  • using_underscores

    ：這種風格的支援者是C++标準庫（看看所有

    std

    命名空間中的名稱）和GUN Foundation的實作人員。

    此外，還有很多其他形式。

• 良好的結尾：選擇字尾是檔案命名的一個組成部分，C/C++的編譯器對于字尾沒有要求，但是将頭檔案命名為

  something.h

  是一種普遍約定，如果不這麼做，就會想在你眼睛裡釘釘子一樣難受。由于缺乏嚴格的規定，我們确實感到有些痛苦，對于C++實作的檔案名存在一些約定，如常見的字尾

  .C

  ,

  .cc

  ,

  .cpp

  ,

  .cxx

  和

  .c++

  等。以

  .hpp

  為字尾的C++檔案雖然不常見，但是也會遇到。你的選擇可能取決于編譯器，個人偏好或編碼标準。關鍵是保持一緻性。選擇一種字尾方案，然後堅持使用下去。
• 不應做的：不要建立具有以下特征的名稱：
  • 含義模糊：方式有千萬種，首字母縮略和簡寫會顯得很随意，而單個字母的名稱則太神秘。
  • 啰嗦：避免使用過于簡潔的名稱，但是也不有建立像

    the_number_of_apples_before_I_start_eating

    這樣的變量，這樣既無趣又無聊。
  • 不準确或使人誤解：顯而易見，應該使你的名稱準确，另外錯誤的拼寫會開辟出一塊困惑的雷區。
  • 有歧義或含糊不清：不要使用可以用多種方式解釋的名稱，例如使用

    data

    或

    value

    這種含糊不清的名稱，除非它們代表的是什麼非常清楚；避免使用

    temp

    或

    tmp

    等含糊不清的名稱，除非你真的必須這麼做；不要通過大小寫或單個字元來區分名稱；不要無故建立其名稱與外部範圍某個對象相同的局部變量。
  • 太做作：有趣的小縮寫，很難記住的聰明的簡寫以及對數字的解釋性使用都應該被避免。對于沒有經驗的人來說，

    internationalization

    的一種常見縮寫

    il8n

    看起來會顯得毫無意義。應該建立清晰，具體，簡潔，準确和無歧義的名稱，使用公共的術語和參照标準。