代碼中到處都須要命名。作為程序猿。我們得給類命名，給變量命名，給函數命名，給參數命名。給命名空間命名，等等等等。以下有20條小貼士能幫助你提高你的命名能力。

1.使用可以表達意圖的名字

名字得能告訴我們它要做什麽，為什麽存在，以及是怎樣工作的。選擇可以表達意圖的名字。將更有利於我們理解代碼。

<span style="font-size:14px;">int d; // elapsed time in days

int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;</span>

在上面的片段中，我們僅僅能從凝視中知道變量d指的是什麽。

於是閱讀代碼的人為了知道它的含義就不得不去尋找它的實例以獲取線索。所以。要是我們可以好好命名這個變量，閱讀代碼的人就行瞬間知道這變量的含義。

2.不要怕在選擇名字上花時間

你應該多試幾種不同的名字，直至足以描寫敘述其含義。千萬不要害怕在這上面花時間。以後閱讀你代碼的人（包含你自己）將會因此而受益。

此外。一個描寫敘述性的名稱甚至還能有助於你在心中理清模塊的設計。良好的命名的確須要花費時間。可是從長遠來看，利大於弊。

3.重構名字

假設你在後面的開發過程中想到了一個更好的名字，那就不要猶豫。立即去改吧。

如今的IDE使得重構名字變得異常easy。

4.避免在名字中出現幹擾詞

比方Manager、Processor、Data、Info以及“我不知道這叫什麽”的同義詞。都是幹擾詞。假設你須要使用上面這些幹擾詞的話，那麽說明你的命名可能太累贅了。

5.小心難以命名的類/功能

一個非常難命名的類或函數非常有可能是一個代碼異味。這說明：

• 代碼做得太多。
• 代碼做得還不夠。
• 你對此問題理解得還不夠透徹。須要先獲取很多其它的信息。

6.類名

類應該有個名詞或名詞詞組的名字，如Customer、WikiPage、Account和AddressParser。繼承性父類應該給個又短又有沖擊力的名字。子類的名字應該長點，通過形容詞來描寫敘述其不同於它的父類之處，如SavingsAccount

7.變量名

變量名也應該是名詞。它們大多是由其指向的類衍生出去的。布爾變量應寫成謂詞的形式，如isEmpty和isTerminated，這樣放到if語句才便於理解。

8.方法名

方法名應該是一個動詞或動詞詞組，如postPayment()、deletePage()和save()。

訪問器和調整器應該分別前綴get和set。返回布爾值的方法應該前綴‘is’，如isPostable()，這樣在if語句中才便於理解。

9.範圍大小與變量名的長度

變量名的長度應和它的範圍大小相匹配。假設變量的範圍非常短，那麽變量名的長度也應該非常短。

反之，變量名則應該長一點。更有描寫敘述性。

10.範圍大小與方法/類名的長度

對於方法和類名的長度則應該與其範圍成反比。對於公共方法。短一點的名字會比較好，這是由於它們會被調用多次。私有方法僅僅在類的範圍內被調用，長一點的名字反而能夠作為文檔使用。此條規則的例外是派生類的名字。類越派生，基類前所加的形容詞就越多。名字也就越長。

11.一個概念一個詞

為某個抽象概念選定一個詞。然後就不要變了。比如作為不同類中的等效方法。get()、fetch()和retrieve()會讓人混淆起來。保持一致的詞匯是程序猿駕馭代碼的重要工具。

12.不要將同一個詞用於兩個不同的概念

假設你遵循第11點——一個概念一個詞的原則，那麽就能夠避免很多有著同樣方法名的類。僅僅要參數列表和各種方法的返回值在語義上是等價的就沒問題。

僅僅有當你將同一個詞用於兩個不同的概念時才會出現故障。

比如。我們能夠在多個類中使用add()方法，通過加入或連接兩個現有的值來創建一個新的值。假設我們之後又須要在類中引入一個add方法用於加入參數到集合中，這就會由於語義不同而導致問題。這樣的新方法最好是改叫為insert()。

13.使用解決方式領域的名字

我們編寫的代碼今後可能會有其它程序猿來閱讀。所以我們使用一些技術術語進行代碼命名會帶來非常大的優點。比方適當地使用算法名字、設計模式名字以及數學術語，這些命名方式非常可能會讓其它程序猿更easy理解程序，引起共鳴。

14.使用問題領域的名字

假設實在找不到易於理解的技術術語來命名，那麽也能夠從問題領域來尋找合適的代碼命名。當未來閱讀你代碼的程序猿不確定代碼意義的時候，這將為他們提供一些問題的線索。

15.加入有意義的語境

大多數名字其本身是沒有意義的，而且須要放到語境（類/函數/命名空間）中，才幹讓閱讀代碼的人理解它們指代的是什麽。在某些情況下，可能須要前綴名稱以補充語境。

比如，如果我們有一些用來表示地址的變量：firstName、lastName、street、houseNumber、city、state和zip。

如果僅僅看state這個變量，我們是非常難判斷出它指的是什麽意思，一個比較好的解決的方法就是將這些變量封裝到Address類中。

16.不要加入沒來由的語境

僅僅要意思明白。短一點的名字通常比長的好，所以不要多此一舉地加入語境。名字前不應該被加綴一些能夠從類/包/命名空間中判斷的不必要的信息。

17.避免編碼

鑒於如今的IDE的強大，我們已經不須要編碼類型和範圍信息到變量名和類名中。

這包含不必加入I至接口，由於使用代碼的用戶不須要知道他們的類正在向接口傳遞。

所以假設你一定要使用編碼。那麽最好是對實現進行編碼而不是接口。

18.避免錯誤的信息

不要給一些錯誤的信息，由於這樣會誤導閱讀代碼的人。

假設你將一個實際支持數組的變量命名為accountList。那就非常easy讓人得出錯誤的結論。

19.使用讀不出來的名字

編程是一個社會化的活動。使用那些讀不出來的名字僅僅會阻礙我們的討論。

20.使用易搜索的名字

使用短而通用的名字會妨礙我們在代碼庫中搜索事物。這對我們操縱代碼和重構非常有影響。

最後，你的代碼一定能夠完美的完畢了，當然還有其它重要的步驟。那就是給代碼加層殼，即加密保護！

不要讓自己好不easy辛辛苦苦寫出來的代碼開發好的程序為他人所利用，防患於未然。

每一個程序猿需掌握的20個代碼命名小貼士