阿里妹導(dǎo)讀：你有沒有遇到過這種情況：過幾周或者幾個月之后，再看到自己寫的代碼，感覺一團(tuán)糟，不禁懷疑人生？我們每天都與代碼打交道，但當(dāng)被問道什么是好的代碼時，很多人可能會先愣一下，然后給出的回答要么比較空泛，要么比較散，沒辦法簡單明了地概括出來。今天，我們就來說什么是好的代碼？

一句話概括
衡量代碼質(zhì)量的唯一有效標(biāo)準(zhǔn)：WTF/min —— Robert C. Martin

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

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

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

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

所以，談到好代碼，首先跳入自己腦子里的一個詞就是：整潔。好的代碼一定是整潔的，給閱讀的人一種如沐春風(fēng)，賞心悅目的感覺。

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

好代碼的特性

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

高內(nèi)聚低耦合

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

• 開閉原則OCP (The Open-Close Principle)
• 單一職責(zé)原則SRP (Single Responsibility Principle)
• 依賴倒置原則DIP (Dependence Inversion Principle)
• 最少知識原則LKP (Least Knowledge Principle)) / 迪米特法則 (Law Of Demeter)
• 里氏替換原則LSP (Liskov Substitution Principle)
• 接口隔離原則ISP (Interface Segregation Principle)
• 組合/聚合復(fù)用原則CARP (Composite/Aggregate Reuse Principle)

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

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

可讀性

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

| 命名

大到項(xiàng)目名、包名、類名，小到方法名、變量名、參數(shù)名，甚至是一個臨時變量的名稱，其命名都是很嚴(yán)肅的事，好的名字需要斟酌。
名副其實(shí)：好的名稱一定是名副其實(shí)的，不需要注釋解釋即可明白其含義的。

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

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

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

可讀的：名稱一定是可讀的，易讀的，最好不要用自創(chuàng)的縮寫，或者中英文混寫。
足夠短：名稱當(dāng)然不是越長越好，應(yīng)該在足夠表達(dá)其含義的情況下越短越好。

| 格式

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

垂直格式：通常一行只寫一個表達(dá)式或者子句。一組代碼代表一個完整的思路，不同組的代碼中間用空行間隔。

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);} }

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

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)變量、實(shí)體變量應(yīng)定義在類的頂部。類內(nèi)方法定義順序依次是：公有方法或保護(hù)方法 > 私有方法 > getter/setter方法。

水平格式：要有適當(dāng)?shù)目s進(jìn)和空格。

團(tuán)隊(duì)統(tǒng)一：通常，同一個團(tuán)隊(duì)的風(fēng)格盡量保持一致。集團(tuán)對于Java開發(fā)進(jìn)行了非常詳細(xì)的規(guī)范。

| 類與函數(shù)

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

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

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

| 注釋

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

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

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

| 錯誤處理

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

拋出異常時提供足夠多的環(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)的時機(jī)，我認(rèn)為當(dāng)代碼有壞味道的時候，也代表了其并不是好的代碼。

代碼的壞味道

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

重復(fù)：Martin Fowler也認(rèn)為壞味道中首當(dāng)其沖的就是重復(fù)代碼。很多時候，當(dāng)我們消除了重復(fù)代碼之后，發(fā)現(xiàn)代碼就已經(jīng)比原來整潔多了。

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

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

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

發(fā)散式變化、霰彈式修改、依戀情結(jié)：如果一個類不是單一職責(zé)的，則不同的變化可能都需要修改這個類，說明存在發(fā)散式變化，應(yīng)考慮將不同的變化分離開。

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

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

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

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

總結(jié)

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

我認(rèn)為僅僅編寫出可運(yùn)行的代碼是遠(yuǎn)遠(yuǎn)不夠的，還要時刻注意代碼的整潔度，留下一些漂亮的代碼。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的这一团糟的代码，真的是我写的？！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。