寫程式碼非常簡單，可是優雅的程式碼，卻不是每個人都可以寫出來的，不在於難度，而在於，很多人寫程式碼完全不為他人和團隊多想一點，只顧眼下自己一畝三分地的功能實現；寫優雅的程式碼，難度不在技術，在於為人處世的方式。分享一篇文章，寫的非常好，程式碼規範非常多，但總有些基本點是必須要遵守的

Any fool can write code that a computer can understandGood programmers write code that humans can understand

普通的工程師堆砌程式碼，優秀的工程師優雅程式碼，卓越的工程師簡化程式碼。如何寫出優雅整潔易懂的程式碼是一門學問，也是軟體工程實踐裡重要的一環。筆者推薦三本經典的書籍《程式碼整潔之道 》、《編寫可讀程式碼的藝術》、《重構:改善既有程式碼的設計》，下文重點將從註釋、命名、方法、異常、單元測試等多個方面總結了一些程式碼整潔最佳實踐，大部分是筆者總結於以上三本書中的精華，也有部分是筆者工程實踐的總結。篇幅有限，本文將總結性給出一些實踐建議，後續會有文章來給出一些程式碼整潔之道的事例。

註釋

不要給不好的名字加註釋，一個好的名字比好的註釋更重要
不要“柺杖註釋”，好程式碼 > 壞程式碼 + 好註釋
在檔案/類級別使用全域性註釋來解釋所有部分如何工作
一定要給常量加註釋
團隊統一定義標記
TODO 待處理的問題
FIXME 已知有問題的程式碼
HACK 不得不採用的粗糙的解決方案

在註釋中用精心挑選的輸入輸出例子進行說明
註釋應該宣告程式碼的高層次意圖，而非明顯的細節
不要在程式碼中加入程式碼的著作資訊，git可以乾的事情不要交給程式碼
原始碼中的html註釋是一種厭物, 增加閱讀難度
註釋一定要描述離它最近的程式碼
註釋一定要與程式碼對應
公共api需要添加註釋，其它程式碼謹慎使用註釋
典型的爛註釋
不恰當的資訊
廢棄的註釋
冗餘註釋
糟糕的註釋
註釋掉的程式碼

唯一真正好的註釋是你想辦法不去寫的註釋
不要有循規式註釋，比如setter/getter註釋
不要新增日誌式註釋，比如修改時間等資訊（git可以做的事情）
註釋一定是表達程式碼之外的東西，程式碼可以包含的內容，註釋中一定不要出現
如果有必要註釋，請註釋意圖（why），而不要去註釋實現（how)，大家都會看程式碼
適當新增警示註釋

命名

儘可能使用標準命名方法，比如設計模式，通用學術名詞等
命名要找更有表現力的詞
使用更專業的詞，比如不用get而使用fetch或者download
避免空泛的名字，像tmp
使用具體的名字來細緻的描述事物
給變數名帶上重要的細節，比如加上單位ms等
為作用域大的名字採用更長的名字，作用域小的使用短名字
變數型別為布林值表達加上is，has，can，should這樣的詞會更明確

變數名稱長短應該與其作用域對應
別害怕長名稱，長而具有描述性的名稱比短而令人費解的名稱好

方法

函式不應該有100行那麼長，20行封頂最好
if else while等控制語句其中程式碼塊應該只有一行，也就是一個函式呼叫語句
函式的鎖進層次不應該多於兩層
一個函式只做一件事，一個函式不應該能抽象出另外一個函式

某個公共函式呼叫的私有函式緊隨其後
最理想的引數是零引數，最長不要超過三個入參，儘量不要輸出引數
如果函式傳入三個及以上引數最好將其抽象為類
標識引數十分醜陋，向函式傳入布林值用於區分不同業務的做法很醜陋，應該拆分為多個函式

別返回null值，丟擲異常或者返回特殊物件，儘量避免NPE
別傳入null值

異常與錯誤

抽離try catch包含的程式碼塊，其中程式碼塊抽象為一個函式
丟擲的每個異常，都應當提供足夠的環境說明，已便判斷錯誤的來源與處所
不要將系統錯誤歸咎於偶然事件

併發

分離併發相關程式碼與其它程式碼
嚴格限制對可能被共享的資料的訪問
避免使用一個共享物件的多個同步方法
保持同步區域微小，儘可能少設計臨界區

單元測試

不要怕單元測試的方法名字太長或者繁瑣，測試函式的名稱就像註釋
不要追求太高的測試覆蓋率，測試程式碼前面90%通常比後面10%花的時間少
使用最簡單的並且能夠完整運用程式碼的測試輸入
給測試函式取一個完整性的描述性名字，比如 Test _
測試程式碼與生產程式碼一樣重要
如果測試程式碼不能保證整潔，你就會很快失去他們
每個測試一個斷言，單個測試中斷言數量應該最小化也就是一個斷言
FIRST原則
快速 Fast
獨立 Independent 測試應該相互獨立
可重複 Repeatable 測試應當在任何環境中重複通過
自足驗證 Self-Validating 測試應該有布林值輸出
及時 Timely 最好的方式是TDD

程式碼結構

程式碼行長度控制在100-120個字元
可能用大多數為200行，最長500行的單個檔案構造出色的系統
關係密切的程式碼應該相互靠近
變數宣告應該靠近其使用位置
若某個函式呼叫了另外一個，應該把他們放在一起，而且呼叫者應該放在被呼叫者上面
自上向下展示函式呼叫依賴順序

應該把解釋條件意圖的函式抽離出來，儘可能將條件表達為肯定形式
不要繼承常量，比如介面中定義常量，不要使用繼承欺騙程式語言的作用範圍規則
模組不應瞭解它所操作物件的內部情況
DTO（Data Transfer Objects）是一個只有公共變數沒有函式的類
物件暴露行為，隱藏資料
不要使用“尤達表示法” 如 if(null == obj)，現代編譯器對if(obj = null)這樣的程式碼會給出警告
一般情況使用if else，簡單語句使用三目運算子
通常來講提早返回可以減少巢狀並讓程式碼整潔

設計

類應該足夠短小
類應該滿足單一權責原則（SRP），類和模組只有一個修改理由
類應該只有少量的實體變數
類應該遵循依賴倒置原則 DIP（Dependency Inversion Principle），類應該依賴於抽象而不是依賴於具體細節
類中的方法越少越好，函式知道的變數越少越好，類擁有的實體變數越少越好

通過減少變數的數量和讓他們儘量“輕量級”來讓程式碼更有可讀性
減少變數
縮小變數的作用域
只寫一次的變數更好，如常量

最好讀的程式碼就是沒有程式碼
從專案中消除不必要的功能，不要過度設計
從新考慮需求，解決版本最簡單的問題，只要能完成工作就行
經常性地通讀標準庫的整個API，保持對他們的熟悉程度

簡單設計
執行所有測試
不可重複
表達了程式設計師的意圖
儘可能減少類和方法的數量
以上規則按重要程度排列

無論是設計系統或者單獨模組，別忘了使用大概可工作的最簡單方案
整潔的程式碼只提供一種而非多種做一件事的途徑，他只有儘量少的依賴。明確定義並提供儘量少的API
減少重複程式碼，提高表達力，提早構建，簡單抽象

希望這篇文章能對大家起到幫助