轉載自公衆號：趣談編程
來源：zsx躍遷路
作者：試心
讓軟件能工作和讓軟件保持整潔，是截然不同的工作，後者需要投入的更多。
大多數人只能更多地把精力放在讓代碼能工作，而沒辦法保持代碼有組織更整潔。能做到代碼整潔，說明你已經不是一般人了。
本文內容主要分以下幾點：
1. 什麼樣的代碼是整潔的
2. 取個好名字
3. 讓函數再整潔一點
4.註釋的好與壞
5. 格式化
6. 異常處理和邊界
7. 整潔的類
1.什麼樣的代碼是整潔的
如上圖所示，衡量代碼質量的唯一標準，是別人閱讀你代碼時的感受。
不整潔的代碼，閱讀體驗是這樣的：
1.亂（組織亂，職責亂，名稱亂起）
2.邏輯不清晰（if-else 太多）
3.繞彎子（簡單的事寫的很複雜）
4.看不懂（只有寫的人能理解）
5.難修改（耦合嚴重，各種寫死）
整潔的代碼，閱讀體驗是這樣的：
1.清晰（是什麼，做了什麼，一眼看得出來）
2.簡單（職責少，代碼少，邏輯少）
3.乾淨（沒有多餘的邏輯）
4.好拓展（依賴的比較少，修改不會影響很多）
接下來介紹一些寫整潔代碼的方法。
2.取個好名字
先看幾個壞命名的例子：
正如上圖所示，壞命名具有這樣的特點：
1.使用縮寫（讓使用者誤解其用途）
2.描述性差（通過命名無法理解他的作用）
3.相似（使用類似的、難分辨的名稱）
4.使用專業術語做名稱容易誤會，比如使用 Activity 表達活動，容易被理解成安卓裏的組件
5.需要借註釋解釋，名稱本身就是解釋，如果還需要藉助註釋，就已經說明這個命名有問題，對應的類、函數、屬性職責不清晰
好的命名具有這樣的特點：
1.名副其實
閱讀名稱就知道它爲什麼存在、做什麼事、應該怎麼用，如果需要通過註釋來回答，那就不算名副其實
2.不容易混淆
避免使用非常相似的名稱，尤其是類型還相同，比如小寫 l 和1、o 和 0、專有名詞
3.讀的出來
不要因爲害怕名稱過長而使用縮寫，那樣不便於和別人討論
4.方便搜索
名稱長度和其作用範圍成正比，作用範圍比較大的，長名稱也可以，只要能表達清楚
3.讓函數再整潔一點
1.函數的第一要則：短小 （多短纔算可以？不超過 10 行，縮進層級不該大於兩層） **
2.只做一件事 （要判斷函數是否做了不止一件事，就看它裏面的代碼，是否能再拆出一個函數）
3.函數變大的頭號兇手：switch 語句
switch 語句天生要做多件事，我們能做的，就是減少 switch 語句的次數，把它埋藏在較低的抽象層級，同時不重複使用 switch
如果有類似的 switch 出現多次，就要考慮使用多態來減少 switch 語句出現的次數
4.定義的函數的參數越多，你耗費函數使用者的青春就越多，使用者需要花時間搞清楚每個參數的具體含義和順序
最理想的參數數量是1~2
從測試的角度看，參數越多，可能出現的用例就越多，就越容易出錯
保持參數列表短小的方法: 參數升爲全局變量、多個參數封裝成一個類
5.不要有副作用（副作用就是做了名稱以外的工作）
6.Android Studio 提供了 Refactor Extract ，幫助我們做代碼拆分
4.註釋的好與壞
在這些場景下，使用註釋比較好：
1.彌補代碼表達意圖的失敗
代碼本身無法說明意圖，這時使用註釋，說明這段代碼需要被修改
2.提供信息
提供代碼以外的信息，比如產品相關信息
3.複雜實現的 簡要概括
讓閱讀者快速瞭解某個複雜的系統
4.警示、提醒
比如某個不起眼的代碼是爲了解決某個 bug，防止別人誤刪
5.TODO
IDE可以定位 TODO 註釋，我們需要定期查看這些註釋，刪除不再需要的，讓代碼整潔
這些註釋是壞註釋：
1.令人費解的註釋
讀懂花費的時間比看代碼的時間還長，差評
2.誤導性註釋，老舊的註釋
代碼纔是真相，註釋有可能是謊言，還是要”少寫註釋！“
3.日誌型註釋
比如記錄修改日誌，放到 git commit 日誌裏吧
4.廢話註釋
變量名、函數名已經很清晰，就不需要註釋，註釋裏不要放一些奇怪的東西，比如如來佛祖
5.註釋掉的代碼
沒用的代碼及時刪除
別給糟糕的代碼寫註釋，重構！
5.格式化 Coding Style
1.團隊最好統一格式化標準
那樣就可以避免某人只修改了一點，但順手格式化了一下，整個類都產生了變動，那樣會覆蓋真正的提交日誌。
2.一行代碼列數不超過 100
Android Studio 裏的豎線默認是 100，不要超過這條線。
3.代碼抽象層級逐漸遞減
最頂應該給出高層次概念和算法，向下逐漸展開細節。
4.用好空行
每個空行代表思路的重新開始，用空白行隔開思路和不同作用的代碼，和寫文章一樣，及時分段。
5.物以類聚
關係密切的代碼應該靠近。
6.異常處理和邊界
1.使用異常替代返回錯誤碼
2.抽離錯誤處理
如果錯誤處理很重要的話，可以考慮把錯誤處理單獨放到一個方法裏。
3.儘量不要返回 null
返回空對象好於返回 null，儘可能的避免空指針的出現。
4.慎用 CheckedException
定義異常時，要考慮它會被如何捕獲。CheckedException 如果不處理，就得強制拋出去，那樣會影響所有調用鏈。
邊界：
1.處理邏輯前，優先處理邊界和異常
2.快速瞭解某個框架的邊界
在使用的框架代碼裏使用關鍵字 throw new 進行搜索，看看什麼情況下會拋出什麼異常，最後整理出來。
3.創建邊界代碼，隔離第三方
使用我們控制不了的代碼時，必須加倍小心，確保未來修改的代碼不會太大。
創建邊界代碼，隔離第三方，避免我們的代碼對第三方框架內部瞭解過多。
7.整潔的類
整潔的類應該具有以下特點：
1.職責少，等於短小
評價類職責的多少，看它對外暴露的方法個數，多於 5 個就可以拆分了。
2.只有一條被修改的理由
根據單一職責原則，類應該只有一條被修改的理由。
3.隔離改變
依賴抽象而非具體；減少對外暴露公有變量，使用 getter 代替。
4.拆分不是壞事
有同學可能會擔心了：拆分類太多會不會更復雜了？
假如你有很多東西，是希望根據分類放放到不同的小抽屜格子裏，還是希望一起放到幾個大抽屜裏？