然而，看似簡單的命名也是很多程序員頭疼的問題。有些朋友，在給變量命名的時候，甚至會用英文給自己熟悉的英文命名。如果需要命名的部分沒有用英文表達，他們可能只是用拼音。
有些童鞋壹下子想不起來怎麽取名字。直接用拼音加aa、bb等字母命名，沒有代表意義。它們的可讀性很差。可能他們今天寫的，壹周後回來就忘了具體代表的意思了。
所以，很多人在寫代碼之前，總是想了又想，應該用什麽命名方法？對於經常在C++、Java、Python等主流語言之間切換的強迫癥患者來說，改變語言和命名風格應該不會太混亂。
既然要做的名字那麽多，不如就做好吧。本期異步君為大家帶來幾個簡單的起好名字要遵循的規則。讓我們來看看。
— 01 —
名副其實
名副其實說起來簡單。我們要強調的是，這件事非常嚴重。選擇壹個好名字需要時間，但是節省的時間比花費的時間多。註意命名，壹旦找到更好的名字，就換掉舊的。這樣做，閱讀妳的代碼的人(包括妳自己)會更開心。
變量、函數或類的名字應該已經回答了所有的大問題。它應該告訴妳它為什麽存在，它是做什麽的，以及應該如何使用它。如果名字需要補充評論，那就名不副實了。
d這個名字說明不了什麽。並沒有引起讀者時間流逝的感覺，更不用說按天計算了。我們應該選擇表示對象和測量單位的名稱:
選擇壹個反映原意的名字，可以讓人們更容易理解和修改代碼。以下代碼的目的是什麽？
為什麽很難解釋上面的代碼要做什麽？沒有復雜的表達式，空格和縮進也中規中矩，只使用了三個變量和兩個常量，甚至沒有涉及其他類或多態方法，只是(或者看起來是)壹個數組列表。
問題不在於代碼的簡潔性，而在於代碼的模糊性:即代碼中沒有清晰反映上下文的程度。上述代碼要求我們知道以下問題的答案:
(1)列表中有哪些種類的東西？
(2)列表中的零度以下標記條目有什麽意義？
(3)值4的含義是什麽？
(4)如何使用返回的列表？
問題的答案沒有體現在代碼段中，但代碼段是它們應該在的地方。例如，我們正在開發壹個掃雷遊戲，我們發現磁盤是壹個名為theList的單元格列表，因此將其名稱改為gameBoard。
磁盤上的每個單元都由壹個簡單的數組表示。我們還發現，零度以下的標記條目是壹個狀態值，狀態值4表示“已標記”。只要改成有意義的名字，代碼就會有相當程度的提升:
註意，代碼的簡單性沒有被觸及。運算符和常數的數量保持不變，嵌套的數量保持不變，但是代碼變得清晰多了。
您可以更進壹步，編寫另壹個類來代替int數組來表示單元格。這個類包含了壹個名副其實的函數(稱為isFlagged)，從而屏蔽了幻數[1]。所以妳得到了壹個新版本的函數:
妳可以很容易地知道發生了什麽事，只要簡單地改變名稱。這就是選擇好名字的力量。
— 02 —
避免誤導
程序員必須避免留下錯誤的線索來隱藏代碼的初衷。應該避免使用與原意相反的詞語。比如hp、aix、sco就不應該作為變量名，因為它們都是Unix平臺或者類Unix平臺的專有名稱。即使妳正在寫壹個三角計算程序，hp看起來是壹個不錯的縮寫[2]，但也可能提供錯誤的信息。
除非是真正的列表類型，否則不要使用accountList來引用壹組帳戶。單詞列表對程序員來說有著特殊的意義。如果裝賬號的容器不是真的列表，就會造成錯誤的判斷。
所以最好使用accountGroup或者bunchOfAccounts，甚至直接使用Accounts。
謹防使用外貌相似度高的名字。例如，需要多長時間來區分Xyzcontroller在壹個地方高效處理字符串和Xyzcontroller在模塊的另壹個地方高效處理字符串？這兩個單詞的形狀如此相似。
用同樣的方式拼寫同樣的概念就是信息。拼寫不壹致會引起誤解。我們喜歡現代Java編程環境的自動代碼完成特性。鍵入名稱的前幾個字母，然後單擊熱鍵組合(如果有)以獲得名稱的可能形式列表。
如果把相似的名字按字母順序放在壹起，而且區別很明顯，那就相當有幫助了，因為程序員很可能不會看妳的詳細註釋，甚至不會看這類方法的列表，直接看名字來選擇壹個對象。
令人誤解的名字的壹個非常可怕的例子是使用小寫字母L和大寫字母O作為變量名，尤其是在組合使用時。當然，問題是它們看起來完全像常數“壹”和“零”。
讀者可能會認為這是純粹的虛構，但我們確實看到過充滿這種名字的代碼。有壹次，代碼作者建議用不同的字體寫變量名，讓它們更清晰，但前提是這個方案要口頭和書面傳遞給所有未來的開發者。後來只是做了壹個簡單的重命名操作就解決了問題，並沒有引起其他問題。
— 03 —
進行有意義的區分
如果程序員只是為了滿足編譯器或解釋器的需求而寫代碼，那就麻煩了。比如，因為同壹個作用域內的兩個不同的東西不能同名，所以妳可能會隨便更改其中壹個的名稱，有時幹脆填錯拼寫，結果就會是編譯器在糾正拼寫錯誤後出錯。
僅僅加上壹個數列或者廢話是不夠的，即使足以讓編譯器滿意。如果名字壹定不壹樣，那麽它們的意思也應該不壹樣。
以數字序列(a1，a2…aN)命名，與依義命名相反。這樣的名字純粹是誤導——它根本沒有提供正確的信息，也沒有提供作者意圖的線索。試試看:
如果參數名改為source和destination，這個函數會更好。
廢話是另壹種無意義的區分。假設妳有壹個產品類。如果有另壹個名為ProductInfo或ProductData的類，它們的名稱不同，但含義相同。信息和數據，像A，an和the，都是含義模糊的無意義的東西。
請註意，使用前綴a和the是正確的，只要它們反映了有意義的差異。例如，您可以將用於域變量，將用於函數參數[5]。但是如果妳已經有了壹個名為zork的變量，還想調用壹個名為theZork的變量，麻煩就來了。
廢話多余。變量壹詞不應出現在變量名中。單詞table不應該出現在表名中。NameString會比Name好嗎？名稱可能是浮點數嗎？如果是這樣，就違反了關於誤導的規定。
假設有壹個名為Customer的類和壹個名為CustomerObject的類。兩者有什麽區別？哪種方式最能表達客戶的歷史付款情況？
有壹個應用反映了這種情況。為了當事人著想，我們改了壹下，但是出錯的代碼真的是這樣的:
程序員如何知道調用哪個函數？
如果沒有明確的約定，那麽變量moneyAmount和money沒有區別，customerInfo和customer沒有區別，accountData和account沒有區別，Message和message沒有區別。要區分名字，就要用讀者能識別區別的方式來區分。
— 04 —
使用易讀的名稱。
人類擅長記憶和使用單詞。大腦有相當壹部分是用來容納和處理文字的。字是可以讀的。令人遺憾的是，人類大腦中有如此大的區域用於處理語音，如果使用不當的話。
名字念不出來，討論起來就像壹只笨鳥。"嘿，這裏，在方塊arr three chee enntee的頂端有壹個名為Peeess Zee Kyew [7]的整數，看到了嗎？"這不是小事，因為編程是壹項社會活動。
有壹家公司在程序中寫了壹個genymdhms(代日、年、月、日、時、分、秒)，壹般讀作“Gen Why EMM·迪·艾奇·EMM ESS”[8]。我有個拼寫每個單詞的壞習慣，所以壹開口就念“gen-yah-mudda-hims”。
後來很多設計師和分析師跟風，聽起來很傻。我們知道這個故事，所以我們認為它很有趣。搞笑是搞笑，其實是在努力抵制不好的命名。在給新開發人員解釋變量名的含義時，他們總是念著傻乎乎的自造詞，而不是正規的英文單詞。比較
現在它讀起來像人類的話:“嘿，邁克，看這張唱片！”生成時間戳[9]設置為明天！不能這麽做？"
— 05 —
使用可搜索的名稱
單字母名稱和數字常量的壹個問題是很難在大文本中找到它們。
找到MAX_CLASSES_PER_STUDENT很容易，但找到數字7很麻煩，它可能是某些文件名或其他常量定義的壹部分，並出現在為不同目的而采用的各種表達式中。如果常數是壹個長數字，它將逃避搜索並導致錯誤。
同樣，e也不是壹個容易搜索的好變量名。它是英語中最常用的字母，它可能出現在每壹個程序和每壹段代碼中。由此可見，長名字比短名字好，搜索到的名字也比自己編的代碼寫的好。
我以為單字母名稱只用於短方法中的局部變量。名稱的長度應該與其作用域大小[N5]相對應。如果壹個變量或常量可能在代碼中的許多地方使用，那麽應該給它壹個易於搜索的名稱。再次比較:
註意上面代碼中的sum並不是壹個特別有用的名字，但至少可以搜索到。用壹個能表達意圖的名字，看似拉長了功能代碼，但想想，WORK_DAYS_PER_WEEK比數字5好找多了，列表中只剩下體現作者意圖的名字。
— 06 —
避免使用編碼。
代碼已經太多了，沒必要自找麻煩。將類型或範圍編碼到名稱中會白白增加解碼的負擔。沒有理由要求每個新人除了要處理的代碼之外，還要懂另壹種編碼“語言”(那很正常)。這對解決問題來說是不必要的負擔。帶代碼的名字通常不方便發音，容易出錯。
匈牙利符號
以前名字的長度很重要的時候，我們打破了不必要編碼的規則，現在後悔了。Fortran語言要求首字母反映類型，這就導致了編碼的出現。BASIC語言的早期版本只允許壹個字母加壹個數字。匈牙利符號[10] (HN)加劇了這種情況。
在Windows C語言API時代，HN非常重要。當時所有的名字要麽是整數句柄，要麽是長指針，要麽是空指針，要麽是string的幾種實現之壹(用途和屬性不同)。那時候編譯器不做類型檢查，程序員需要匈牙利符號來幫助他們記憶類型。
現代編程語言有更豐富的類型體系，編譯器也記住並強制使用類型。而且程序員傾向於使用更小的類和更短的方法，這樣每個變量的定義都在視野範圍內。
Java程序員不需要類型編碼，因為對象是強類型的，代碼編輯環境足夠先進，可以在編譯開始前檢測到類型錯誤！因此，如今HN和其他類型的編碼形式純粹是多余的。它們增加了修改變量、函數或類的名稱或類型的難度，它們增加了閱讀代碼的難度，並且它們產生了編碼系統誤導讀者的可能性。
成員前綴
沒有必要使用m_前綴來表示成員變量。類和函數應該足夠小，以消除對成員前綴的需求。您應該使用可以突出顯示成員或為成員著色的編輯環境。
另外，人們很快就會學會忽略前綴(或後綴)，只看到名字中有意義的部分。看的代碼越多，眼裏的前綴就越少。到頭來，前綴成了不堪入目的浪費，成了舊典的象征。
接口和實現
有時會出現采用編碼的特殊情況。例如，您正在創建壹個用於創建形狀的抽象工廠，它是壹個由具體類實現的接口。工廠和具體班級怎麽命名？IShapeFactory和ShapeFactory？我喜歡不加修飾的界面。首字母I被濫用到了往好裏說是幹擾，往壞裏說是廢話的程度。
我不想讓用戶知道我給了他們壹個接口，只是想讓他們知道這是壹個ShapeFactory。如果我必須在接口和實現中選擇壹個來編碼，我寧願選擇實現。ShapeFactoryImp，甚至是很醜的CShapeFactory，都比編碼接口名強。
-結束-
代碼整潔
作者:[美]羅伯特·c·馬丁
譯者:雷寒
內容介紹:
軟件質量不僅取決於架構和項目管理，還取決於代碼質量。這壹點，無論是敏捷開發派還是傳統開發派，都不得不承認。
這本書提出了代碼的質量與其幹凈程度成正比的觀點。幹凈的代碼質量可靠，為後期的維護和升級打下良好的基礎。作為編程領域的領軍人物，本書作者給出了壹系列有效的幹凈代碼操作實踐。這些實踐在本書中體現為規則(或“啟示”)，並輔以來自實際項目的正反範例。只要遵循這些規則，就能寫出幹凈的代碼，從而有效提高代碼質量。
本書面向所有對提高代碼質量感興趣的程序員和技術經理。書中介紹的規則都來自作者多年的實踐經驗，涵蓋了從命名到重構的諸多編程方面。雖然是“家”的說法，但很有參考價值。