寫程式碼要像寫文章一樣，有始有終、段落分明、一個段落寫一個內容等，細說太多，推薦兩本書《程式碼整潔之道》和《編寫可讀程式碼的藝術》，需要深入細讀。

Any fool can write code that a computer can understand. Good 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這樣的詞會更明確變數名稱長短應該與其作用域對應別害怕長名稱，長而具有描述性的名稱比短而令人費解的名稱好函式名稱應該說明副作用，名稱應該表達函式，變數或類的一切資訊，請不要掩蓋副作用，比如CreateAndReturnXXX

方法

函式不應該有100行那麼長，20行封頂最好if else while等控制語句其中程式碼塊應該只有一行，也就是一個函式呼叫語句函式的鎖進層次不應該多於兩層一個函式只做一件事，一個函式不應該能抽象出另外一個函式某個公共函式呼叫的私有函式緊隨其後最理想的引數是零引數，最長不要超過三個入參，儘量不要輸出引數如果函式傳入三個及以上引數最好將其抽象為類標識引數十分醜陋，向函式傳入布林值用於區分不同業務的做法很醜陋，應該拆分為多個函式別返回null值，丟擲異常或者返回特殊物件，儘量避免NPE別傳入null值

異常與錯誤

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

單元測試

不要怕單元測試的方法名字太長或者繁瑣，測試函式的名稱就像註釋不要追求太高的測試覆蓋率，測試程式碼前面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減少重複程式碼，提高表達力，提早構建，簡單抽象

小結

作為程式碼整潔之道系列的第一篇，本文從註釋、命名、方法，單元測試，併發等視角簡單給出了一些最佳實踐，下文我們會展開來從每個方面介紹更多的實踐事例。相信每一個優秀的工程師都有一顆追求卓越程式碼的心，在程式碼整潔工程實踐上你有哪些好的建議？數百人協作開發的程式碼如何保證程式碼整潔一致性？歡迎大家來討論。

模組化開發，不管什麼樣的業務，牢記程式設計思路！

多多瞭解下設計模式

多看些大神們寫的程式碼，學以致用！

切實的瞭解業務需求！

高效簡潔的程式碼，無非可以分為幾個方面：

1，語法簡潔

2，邏輯簡潔清晰

3，業務架構設計清晰

根據業務邏輯畫出簡單的用例圖，如果不用對外演講的用紙筆跟夥伴們一起討論畫出最優的流程，不一定非得國標符號；根據用例抽象化需求裡的物件，並根據流程建立物件間的關係，用PowerDesigner之類的工具建立E/R資料庫模型與UML業務物件模型，如果是專用系統，物件粒度可以粗一些，物件間的耦合度可以高一些；小夥伴圍繞模型討論並做最後約定後可開工。清晰的模型有效提升程式碼的複用率，將一些複雜關係的業務資料查詢功能放在資料庫端實現，如果喜歡用ORM，一些複雜的關聯查詢可建立檢視或儲存過程再做物件對映，這樣程式碼就可以很高效，很簡潔了。對於開發層面，儘量少用巢狀迴圈，資料庫開發層面我的優先順序一般是巢狀SQL->檢視->儲存過程->自定函式，能一句查詢的都不用游標迴圈。新版MYSQL支援JSON型別欄位，可以把MYSQL當MONGODB用了

程式碼作為程式設計師的主要勞動成果，每個人都希望自己的程式碼高效，簡潔，穩定。但是怎麼做到呢，基於自己的經驗寫幾個方面。

1. 善用工具。俗話說工欲善其事，必先利其器。現代的軟體開發已經遠遠不是二十年前的形式了。一款成熟的IDE提供了排版，糾錯，重構等多項功能，使用好IDE工具會明顯提高自己的程式碼水準。比如前端的vscode或者webstorm，java部分的idea等。

2.不要重複造輪子。軟體發展到今天，各個方向都已經有非常多的第三方元件庫，善用這些成熟的第三方庫，會有效的減少自己程式的bug，同時一般成熟的第三方庫的效能穩定性都是久經驗證，能用就趕緊用吧。

3.持續的改進自己已經寫過的程式碼。不要覺得不出錯的程式就是好程式，程式永遠沒有最完美的。不回顧自己之前的程式，就不會知道問題在哪兒，就會沿著既有思路習慣一直開發新功能，導致工作多年，程式碼質量一直不高。不要怕改錯，出錯了才能更讓你明白問題，會知道如何更好的重構。經典的書籍（重構-改善既有程式碼的設計）裡面對技巧有詳細的說明。

最後說明一點，任何事情需要的都是熱愛並投入，軟體開發尤為如此，如果自己沒有主動性，只是想依靠一些工具之類的來實現程式碼整潔高效，那是不靠譜的，只有熱愛並且持續的學習改進，才是最好的方法。

收個尾：把每個軟體作品都看作自己的孩子，像對待自己孩子一樣好好對待自己寫過的每一行程式碼！