名字得能告訴我們它要做什麼，為什麼存在，以及是如何工作的。選擇能夠表達意圖的名字，將更有利於我們理解程式碼。
int d; // elapsed time in days int elapsedTimeInDays; int daysSinceCreation; int daysSinceModification; int fileAgeInDays;在上面的片段中，我們只能從註釋中知道變數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://www.codeceo.com/article/20-naming-tips-programmer-know.html
英文原文：20 Tips for Better Naming
翻譯作者：碼農網 – 小峰
來自：PHP100
評論(1)