每一個程序員需掌握的20個代碼命名

代碼中處處都須要命名。做爲程序員，咱們得給類命名，給變量命名，給函數命名，給參數命名，給命名空間命名，等等等等。下面有20條小貼士能幫助你提升你的命名能力。

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

名字得能告訴咱們它要作什麼，爲何存在，以及是如何工做的。選擇可以表達意圖的名字，將更有利於咱們理解代碼。

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

在上面的片斷中，咱們只能從註釋中知道變量d指的是什麼。因而閱讀代碼的人爲了知道它的含義就不得不去尋找它的實例以獲取線索。因此，要是咱們可以好好命名這個變量，閱讀代碼的人就可以瞬間知道這變量的含義。

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

你應該多試幾種不一樣的名字，直至足以描述其含義，千萬不要懼怕在這上面花時間。之後閱讀你代碼的人（包括你本身）將會所以而受益。此外，一個描述性的名稱甚至還能有助於你在心中理清模塊的設計。良好的命名的確須要花費時間，可是從長遠來看，利大於弊。

3.重構名字

若是你在後面的開發過程當中想到了一個更好的名字，那就不要猶豫，立刻去改吧。如今的IDE使得重構名字變得異常容易。

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

好比Manager、Processor、Data、Info以及「我不知道這叫什麼」的同義詞，都是干擾詞。若是你須要使用上面這些干擾詞的話，那麼說明你的命名可能太累贅了。

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

一個很難命名的類或函數頗有多是一個代碼異味。這說明：

• 代碼作得太多。
• 代碼作得還不夠。
• 你對此問題理解得還不夠透徹，須要先獲取更多的信息。

6.類名

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

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.使用解決方案領域的名字

咱們編寫的代碼從此可能會有其餘程序員來閱讀，因此咱們使用一些技術術語進行代碼命名會帶來很大的好處。好比適當地使用算法名字、設計模式名字以及數學術語，這些命名方式極可能會讓其餘程序員更容易理解程序，引發共鳴。

14.使用問題領域的名字

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

15.添加有意義的語境

大多數名字其自己是沒有意義的，而且須要放到語境（類/函數/命名空間）中，才能讓閱讀代碼的人理解它們指代的是什麼。在某些狀況下，可能須要前綴名稱以補充語境。例如，假設咱們有一些用來表示地址的變量：firstName、lastName、street、houseNumber、city、state和zip。若是隻看state這個變量，咱們是很難推斷出它指的是什麼意思，一個比較好的解決辦法就是將這些變量封裝到Address類中。

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

只要意思明確，短一點的名字一般比長的好，因此不要畫蛇添足地添加語境。名字前不該該被加綴一些能夠從類/包/命名空間中推斷的沒必要要的信息。

17.避免編碼

鑑於如今的IDE的強大，咱們已經不須要編碼類型和範圍信息到變量名和類名中。這包括沒必要添加I至接口，由於使用代碼的用戶不須要知道他們的類正在向接口傳遞。因此若是你必定要使用編碼，那麼最好是對實現進行編碼而不是接口。

18.避免錯誤的信息

不要給一些錯誤的信息，由於這樣會誤導閱讀代碼的人。若是你將一個實際支持數組的變量命名爲accountList，那就很容易讓人得出錯誤的結論。

19.使用讀不出來的名字

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

20.使用易搜索的名字

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

最後，你的代碼必定能夠完美的完成了，固然還有其餘重要的步驟，那就是給代碼加層殼，即加密保護！不要讓本身好不容易辛辛苦苦寫出來的代碼開發好的程序爲他人所利用，防患於未然！

轉：http://blog.csdn.net/lz201234/article/details/44774647