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

名字得能告訴我們它要做什么，為什么存在，以及是如何工作的。選擇能夠表達(dá)意圖的名字，將更有利于我們理解代碼。

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

在上面的片段中，我們只能從注釋中知道變量d指的是什么。于是閱讀代碼的人為了知道它的含義就不得不去尋找它的實(shí)例以獲取線索。所以，要是我們能夠好好命名這個(gè)變量，閱讀代碼的人就能夠瞬間知道這變量的含義。

你應(yīng)該多試幾種不同的名字，直至足以描述其含義，千萬(wàn)不要害怕在這上面花時(shí)間。以后閱讀你代碼的人（包括你自己）將會(huì)因此而受益。此外，一個(gè)描述性的名稱甚至還能有助于你在心中理清模塊的設(shè)計(jì)。良好的命名的確需要花費(fèi)時(shí)間，但是從長(zhǎng)遠(yuǎn)來(lái)看，利大于弊。

如果你在后面的開(kāi)發(fā)過(guò)程中想到了一個(gè)更好的名字，那就不要猶豫，馬上去改吧?，F(xiàn)在的IDE使得重構(gòu)名字變得異常容易。

比如Manager、PRocessor、Data、Info以及“我不知道這叫什么”的同義詞，都是干擾詞。如果你需要使用上面這些干擾詞的話，那么說(shuō)明你的命名可能太累贅了。

一個(gè)很難命名的類或函數(shù)很有可能是一個(gè)代碼異味。這說(shuō)明：

• 代碼做得太多。
• 代碼做得還不夠。
• 你對(duì)此問(wèn)題理解得還不夠透徹，需要先獲取更多的信息。

類應(yīng)該有個(gè)名詞或名詞詞組的名字，如Customer、Wikipage、Account和AddressParser。繼承性父類應(yīng)該給個(gè)又短又有沖擊力的名字。子類的名字應(yīng)該長(zhǎng)點(diǎn)，通過(guò)形容詞來(lái)描述其不同于它的父類之處，如SavingsAccount衍生于Account。

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

方法名應(yīng)該是一個(gè)動(dòng)詞或動(dòng)詞詞組，如postPayment()、deletePage()和save()。訪問(wèn)器和調(diào)整器應(yīng)該分別前綴get和set。返回布爾值的方法應(yīng)該前綴‘is’，如isPostable()，這樣在if語(yǔ)句中才便于理解。

變量名的長(zhǎng)度應(yīng)和它的范圍大小相匹配。如果變量的范圍很短，那么變量名的長(zhǎng)度也應(yīng)該很短。反之，變量名則應(yīng)該長(zhǎng)一點(diǎn)，更有描述性。

對(duì)于方法和類名的長(zhǎng)度則應(yīng)該與其范圍成反比。對(duì)于公共方法，短一點(diǎn)的名字會(huì)比較好，這是因?yàn)樗鼈儠?huì)被調(diào)用多次。私有方法只在類的范圍內(nèi)被調(diào)用，長(zhǎng)一點(diǎn)的名字反而可以作為文檔使用。此條規(guī)則的例外是派生類的名字。類越派生，基類前所加的形容詞就越多，名字也就越長(zhǎng)。

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

如果你遵循第11點(diǎn)——一個(gè)概念一個(gè)詞的原則，那么就可以避免許多有著相同方法名的類。只要參數(shù)列表和各種方法的返回值在語(yǔ)義上是等價(jià)的就沒(méi)問(wèn)題。只有當(dāng)你將同一個(gè)詞用于兩個(gè)不同的概念時(shí)才會(huì)出現(xiàn)問(wèn)題。

例如，我們可以在多個(gè)類中使用add()方法，通過(guò)添加或連接兩個(gè)現(xiàn)有的值來(lái)創(chuàng)建一個(gè)新的值。如果我們之后又需要在類中引入一個(gè)add方法用于添加參數(shù)到集合中，這就會(huì)因?yàn)檎Z(yǔ)義不同而導(dǎo)致問(wèn)題。這種新方法最好是改叫為insert()。

我們編寫的代碼今后可能會(huì)有其他程序員來(lái)閱讀，所以我們使用一些技術(shù)術(shù)語(yǔ)進(jìn)行代碼命名會(huì)帶來(lái)很大的好處。比如適當(dāng)?shù)厥褂盟惴?、設(shè)計(jì)模式名字以及數(shù)學(xué)術(shù)語(yǔ)，這些命名方式很可能會(huì)讓其他程序員更容易理解程序，引起共鳴。

如果實(shí)在找不到易于理解的技術(shù)術(shù)語(yǔ)來(lái)命名，那么也可以從問(wèn)題領(lǐng)域來(lái)尋找合適的代碼命名。當(dāng)未來(lái)閱讀你代碼的程序員不確定代碼意義的時(shí)候，這將為他們提供一些問(wèn)題的線索。

大多數(shù)名字其本身是沒(méi)有意義的，并且需要放到語(yǔ)境（類/函數(shù)/命名空間）中，才能讓閱讀代碼的人理解它們指代的是什么。在某些情況下，可能需要前綴名稱以補(bǔ)充語(yǔ)境。例如，假設(shè)我們有一些用來(lái)表示地址的變量：firstName、lastName、street、houseNumber、city、state和zip。如果只看state這個(gè)變量，我們是很難推斷出它指的是什么意思，一個(gè)比較好的解決辦法就是將這些變量封裝到Address類中。

只要意思明確，短一點(diǎn)的名字通常比長(zhǎng)的好，所以不要多此一舉地添加語(yǔ)境。名字前不應(yīng)該被加綴一些可以從類/包/命名空間中推斷的不必要的信息。

鑒于現(xiàn)在的IDE的強(qiáng)大，我們已經(jīng)不需要編碼類型和范圍信息到變量名和類名中。這包括不必添加I至接口，因?yàn)槭褂么a的用戶不需要知道他們的類正在向接口傳遞。所以如果你一定要使用編碼，那么最好是對(duì)實(shí)現(xiàn)進(jìn)行編碼而不是接口。

不要給一些錯(cuò)誤的信息，因?yàn)檫@樣會(huì)誤導(dǎo)閱讀代碼的人。如果你將一個(gè)實(shí)際支持?jǐn)?shù)組的變量命名為accountList，那就很容易讓人得出錯(cuò)誤的結(jié)論。

編程是一個(gè)社會(huì)化的活動(dòng)，使用那些讀不出來(lái)的名字只會(huì)阻礙我們的討論。

使用短而通用的名字會(huì)妨礙我們?cè)诖a庫(kù)中搜索事物。這對(duì)我們操縱代碼和重構(gòu)很有影響。

最后，你的代碼一定可以完美的完成了，當(dāng)然還有其他重要的步驟，那就是給代碼加層殼，即加密保護(hù)！不要讓自己好不容易辛辛苦苦寫出來(lái)的代碼開(kāi)發(fā)好的程序?yàn)樗怂?，防患于未然?/p>

轉(zhuǎn)：http://blog.csdn.net/lz201234/article/details/44774647