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等古怪的名稱。它們很容易悄悄混入代碼，雖然一開始人們會以爲挺有趣，可是之後會形成不少混亂。顯而易見的是，職業化就意味着在命名時不要使用語氣助詞。

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

附上一些相關的內容：

• 匈牙利命名法：是一種有爭議的命名約定，他將關於變量或函數的類型信息編入它們的名稱，認爲這樣會使代碼更易於閱讀和維護。這種命名法最初是在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看起來會顯得毫無心義。應該建立清晰，具體，簡潔，準確和無歧義的名稱，使用公共的術語和參照標準。