什么樣的代碼叫好代碼？

送大家以下java學習資料

簡介： 我們每天都與代碼打交道，但當被問道什么是好的代碼時，很多人可能會先愣一下，然后給出的回答要么比較空泛，要么比較散，沒辦法簡單明了地概括出來。顯然，這個問題并沒有唯一的標準答案，誰都可以談論自己的理解，今天談談我對于好代碼的理解。

導讀：我們每天都與代碼打交道，但當被問道什么是好的代碼時，很多人可能會先愣一下，然后給出的回答要么比較空泛，要么比較散，沒辦法簡單明了地概括出來。顯然，這個問題并沒有唯一的標準答案，誰都可以談論自己的理解，今天談談我對于好代碼的理解。

一句話概括

衡量代碼質(zhì)量的唯一有效標準：WTF/min —— Robert C. Martin

Bob大叔對于好代碼的理解非常有趣，對我也有很大的啟發(fā)。我們編寫的代碼，除了用于機器執(zhí)行產(chǎn)生我們預期的效果以外，更多的時候是給人讀的，這個讀代碼的可能是后來的維護人員，更多時候是一段時間后的作者本人。

我敢打賭每個人都遇到過這樣的情況：過幾周或者幾個月之后，再看到自己寫的代碼，感覺一團糟，不禁懷疑人生。

我們自己寫的代碼，一段時間后自己看尚且如此，更別提拿給別人看了。

任何一個傻瓜都能寫出計算機可以理解的代碼。唯有寫出人類容易理解的代碼，才是優(yōu)秀的程序員。—— Martin Fowler

所以，談到好代碼，首先跳入自己腦子里的一個詞就是：整潔。

好的代碼一定是整潔的，給閱讀的人一種如沐春風，賞心悅目的感覺。

整潔的代碼如同優(yōu)美的散文。—— Grady Booch

好代碼的特性

很難給好的代碼下一個定義，相信很多人跟我一樣不會認為整潔的代碼就一定是好代碼，但好代碼一定是整潔的，整潔是好代碼的必要條件。整潔的代碼一定是高內(nèi)聚低耦合的，也一定是可讀性強、易維護的。

高內(nèi)聚低耦合

高內(nèi)聚低耦合幾乎是每個程序員員都會掛在嘴邊的，但這個詞太過于寬泛，太過于正確，所以聰明的編程人員們提出了若干面向?qū)ο笤O(shè)計原則來衡量代碼的優(yōu)劣：

開閉原則 OCP (The Open-Close Principle)單一職責原則 SRP (Single Responsibility Principle)依賴倒置原則 DIP (Dependence Inversion Principle)

最少知識原則 LKP (Least Knowledge Principle)) / 迪米特法則 (Law Of Demeter)

里氏替換原則 LSP (Liskov Substitution Principle)接口隔離原則 ISP (Interface Segregation Principle)組合/聚合復用原則 CARP (Composite/Aggregate Reuse Principle)

這些原則想必大家都很熟悉了，是我們編寫代碼時的指導方針，按照這些原則開發(fā)的代碼具有高內(nèi)聚低耦合的特性。換句話說，我們可以用這些原則來衡量代碼的優(yōu)劣。

但這些原則并不是死板的教條，我們也經(jīng)常會因為其他的權(quán)衡（例如可讀性、復雜度等）違背或者放棄一些原則。比如子類擁有特性的方法時，我們很可能打破里氏替換原則。再比如，單一職責原則跟接口隔離原則有時候是沖突的，我們通常會舍棄接口隔離原則，保持單一職責。只要打破原則的理由足夠充分，也并不見得是壞的代碼。

可讀性

代碼只要具有了高內(nèi)聚和低耦合就足夠好了嗎？并不見得，我認為代碼還必須是易讀的。好的代碼無論是風格、結(jié)構(gòu)還是設(shè)計上都應該是可讀性很強的。可以從以下幾個方面考慮整潔代碼，提高可讀性。

命名

大到項目名、包名、類名，小到方法名、變量名、參數(shù)名，甚至是一個臨時變量的名稱，其命名都是很嚴肅的事，好的名字需要斟酌。

? 名副其實

好的名稱一定是名副其實的，不需要注釋解釋即可明白其含義的。

/** * 創(chuàng)建后的天數(shù) **/ int d; int daysSinceCreation;

后者比前者的命名要好很多，閱讀者一下子就明白了變量的意思。

? 容易區(qū)分

我們很容易就會寫下非常相近的方法名，僅從名稱無法區(qū)分兩者到底有啥區(qū)別（eg. getAccount()與getAccountInfo()），這樣在調(diào)用時也很難抉擇要用哪個，需要去看實現(xiàn)的代碼才能確定。

? 可讀的

名稱一定是可讀的，易讀的，最好不要用自創(chuàng)的縮寫，或者中英文混寫。

? 足夠短

名稱當然不是越長越好，應該在足夠表達其含義的情況下越短越好。

格式

良好的代碼格式也是提高可讀性非常重要的一環(huán)，分為垂直格式和水平格式。

? 垂直格式

通常一行只寫一個表達式或者子句。一組代碼代表一個完整的思路，不同組的代碼中間用空行間隔。

public class Demo { @Resource private List<Handler> handlerList; private Map<TypeEnum, Handler> handlerMap = new ConcurrentHashMap<>(); @PostConstruct private void init() { if (!CollectionUtils.isEmpty(handlerList)) { for (Handler handler : handlerList) { handlerMap.put(handler.getType(), handler); } } } publicResult<Map<String, Object>> query(Long id, TypeEnum typeEnum) { Handler handler = handlerMap.get(typeEnum); if (null == handler) { return Result.returnFailed(ErrorCode.CAN_NOT_HANDLE); } return handler.query(id); } }

如果去掉了空行，可讀性大大降低。

public class Demo { @Resource private List<Handler> handlerList; private Map<TypeEnum, Handler> handlerMap = new ConcurrentHashMap<>(); @PostConstruct private void init() { if (!CollectionUtils.isEmpty(handlerList)) { for (Handler handler : handlerList) { handlerMap.put(handler.getType(), handler); } } } public Result<Map<String, Object>> query(Long id, TypeEnum typeEnum) { Handler handler = handlerMap.get(typeEnum); if (null == handler) { return Result.returnFailed(ErrorCode.CAN_NOT_HANDLE); } return handler.query(id); } }

類靜態(tài)變量、實體變量應定義在類的頂部。類內(nèi)方法定義順序依次是：公有方法或保護方法 > 私有方法 > getter/setter 方法。

? 水平格式

要有適當?shù)目s進和空格。

? 團隊統(tǒng)一

通常，同一個團隊的風格盡量保持一致。集團對于 Java 開發(fā)進行了非常詳細的規(guī)范。（可點擊下方閱讀原文，了解更多內(nèi)容）

類與函數(shù)

? 類和函數(shù)應短小，更短小

類和函數(shù)都不應該過長（集團要求函數(shù)長度最多不能超過 80 行），過長的函數(shù)可讀性一定差，往往也包含了大量重復的代碼。

? 函數(shù)只做一件事（同一層次的事）

同一個函數(shù)的每條執(zhí)行語句應該是統(tǒng)一層次的抽象。例如，我們經(jīng)常會寫一個函數(shù)需要給某個 DTO 賦值，然后再調(diào)用接口，接著返回結(jié)果。那么這個函數(shù)應該包含三步：DTO 賦值，調(diào)用接口，處理結(jié)果。如果函數(shù)中還包含了 DTO 賦值的具體操作，那么說明此函數(shù)的執(zhí)行語句并不是在同一層次的抽象。

? 參數(shù)越少越好

參數(shù)越多的函數(shù)，調(diào)用時越麻煩。盡量保持參數(shù)數(shù)量足夠少，最好是沒有。

注釋

? 別給糟糕的代碼加注釋，重構(gòu)他

注釋不能美化糟糕的代碼。當企圖使用注釋前，先考慮是否可以通過調(diào)整結(jié)構(gòu)，命名等操作，消除寫注釋的必要，往往這樣做之后注釋就多余了。

? 好的注釋提供信息、表達意圖、闡釋、警告

我們經(jīng)常遇到這樣的情況：注釋寫的代碼執(zhí)行邏輯與實際代碼的邏輯并不符合。大多數(shù)時候都是因為代碼變化了，而注釋并沒有跟進變化。所以，注釋最好提供一些代碼沒有的額外信息，展示自己的設(shè)計意圖，而不是寫具體如何實現(xiàn)。

? 刪除掉注釋的代碼

git等版本控制已經(jīng)幫我們記錄了代碼的變更歷史，沒必要繼續(xù)留著過時的代碼，注釋的代碼也會對閱讀等造成干擾。

錯誤處理

? 錯誤處理很重要，但他不能搞亂代碼邏輯

錯誤處理應該集中在同一層處理，并且錯誤處理的函數(shù)最好不包含其他的業(yè)務邏輯代碼，只需要處理錯誤信息即可。

? 拋出異常時提供足夠多的環(huán)境和說明，方便排查問題

異常拋出時最好將執(zhí)行的類名，關(guān)鍵數(shù)據(jù)，環(huán)境信息等均拋出，此時自定義的異常類就派上用場了，通過統(tǒng)一的一層處理異常，可以方便快速地定位到問題。

? 特例模型可消除異常控制或者 null 判斷

大多數(shù)的異常都是來源于NPE，有時候這個可以通過 Null Object 來消除掉。

? 盡量不要返回 null ，不要傳 null 參數(shù)

不返回 null 和不傳 null 也是為了盡量降低 NPE 的可能性。

如何判斷不是好的代碼

討論了好代碼的必要條件，我們再來看看好代碼的否定條件：什么不是好的代碼。Kent Beck 使用味道來形容重構(gòu)的時機，我認為當代碼有壞味道的時候，也代表了其并不是好的代碼。

代碼的壞味道

? 重復

重復可能是軟件中一切邪惡的根源。—— Robert C.Martin

Martin Fowler 也認為壞味道中首當其沖的就是重復代碼。

很多時候，當我們消除了重復代碼之后，發(fā)現(xiàn)代碼就已經(jīng)比原來整潔多了。

? 函數(shù)過長、類過大、參數(shù)過長

過長的函數(shù)解釋能力、共享能力、選擇能力都較差，也不易維護。

過大的類代表了類做了很多事情，也常常有過多的重復代碼。

參數(shù)過長，不易理解，調(diào)用時也容易出錯。

? 發(fā)散式變化、霰彈式修改、依戀情結(jié)

如果一個類不是單一職責的，則不同的變化可能都需要修改這個類，說明存在發(fā)散式變化，應考慮將不同的變化分離開。

如果某個變化需要修改多個類的方法，則說明存在霰彈式修改，應考慮將這些需要修改的方法放入同一個類。

如果函數(shù)對于某個類的興趣高于了自己所處的類，說明存在依戀情結(jié)，應考慮將函數(shù)轉(zhuǎn)移到他應有的類中。

? 數(shù)據(jù)泥團

有時候會發(fā)現(xiàn)三四個相同的字段，在多個類和函數(shù)中均出現(xiàn)，這時候說明有必要給這一組字段建立一個類，將其封裝起來。

? 過多的 if...else 或者使用 switch

過多的 if...else 或者 switch ，都應該考慮用多態(tài)來替換掉。甚至有些人認為除個別情況外，代碼中就不應該存在 if...else 。

總結(jié)

本文首先一句話概括了我認為的好代碼的必要條件：整潔，接著具體分析了整潔代碼的特點，又分析了好代碼的否定條件：什么樣的代碼不是好的代碼。僅是本人的一些見解，希望對各位以后的編程有些許的幫助。

我認為僅僅編寫出可運行的代碼是遠遠不夠的，還要時刻注意代碼的整潔度，留下一些漂亮的代碼，希望寫的代碼都能保留并運行 102 年！

后續(xù)增加一些實際的例子來說明好的和壞的代碼；分享下如何編寫整潔代碼——自己認為有用的一些編程技巧。