>[success] # 表達原則 **代碼的可讀性差，沒能很好地串聯起代碼內在的邏輯**,常見的 * 接手維護項目，卻發現文檔缺失、代碼無注釋，加上維護人離職，基本只能靠猜來梳理代碼邏輯。 * 代碼風格過于抽象（命名過短、魔鬼數字、重名方法等），看不懂，也不敢輕易修改。 * 運行代碼出現故障時，不打日志，不拋異常，導致定位問題需要耗費很長時間。 * 大段的`if-else`代碼嵌套組合，調用邏輯復雜冗長，擴展性差，重構優化費時、費力。 >[danger] ##### 提升代碼可讀性代碼特點 1. **易于維護**，設計文檔、需求文檔和口頭交流只能表達部分業務邏輯的意圖。可讀性高的代碼，能讓閱讀者在閱讀時快速理解編寫者的意圖 2. **易于重構**，代碼的可讀性太差在某種程度上決定了你重構意愿的大小 3. **易于測試**，可讀性高的代碼，參數與輸出都更清晰，在測試時能更精準地找到對應邏輯和問題點 4. **易于應用設計模式**，好讀懂代碼跟方便理解分析出要使用較好的設計模式進行重構 >[danger] ##### 表達原則 表達原則（Program Intently and Expressively，簡稱 PIE），起源于敏捷編程，是指編程時應該有清晰的編程意圖，并通過代碼明確地表達出來，**代碼即文檔**，在開發代碼時，**應該更注重代碼表達的意圖是否清晰** * **代碼表現形式**：在命名（變量名、方法名、類名）、代碼格式、注釋等方面的改進,無論是變量名、類名還是方法名，好的名字能快速準確地傳達要表達的含義，而縮寫、自定義名稱會讓代碼變得難以理解,命名的優化加上注釋的說明讓源代碼的邏輯變得清晰起 * **控制流和邏輯**：盡量分離控制流和邏輯，讓代碼變得更容易理解,如果過多`if`嵌套無法保證邏輯簡單清晰 * **慣性思維**：找出常犯的一些慣性思考方式并逐一改進，**要避免一次性代碼**一次性代碼一旦修改需要，多處就得跟著修改，而多次修改又可能會出現遺漏的風險，**要避免復制粘貼代碼**復制代碼往往都對內部邏輯不了解，等真正出現問題時候再去修改發現梳理邏輯更加困難， **避免寫超長代碼**，**避免過度簡化命名和表達式**，**避免寫是什么的注釋**，代碼的命名和結構如果能直接反映出來“是什么”的話，我們就不應該用注釋去表達，因為看代碼一眼就能明白，應該多寫“為什么”的注釋，比如，為什么要多加一個適配的方法，原因可能是線上 xxx 問題引起，或臨時修復的Bug，后續可能隨 xxx 接口調整而廢棄，“為什么”的注釋還有一個好處：尤其在早期快速迭代過程中，能給后來的維護者提供一個優化的切入點，而不至于交接代碼后讓維護代碼的人看不懂、不敢動 **表達原則的核心思想在于：通過代碼清晰地表達我們的真實意圖**，雖然軟件開發過程中會有諸多文檔，比如，架構設計文檔、流程文檔、PRD 文檔等，但這些文檔并不足以幫助我們正確理解代碼是如何運行和組織的，很多時候我們只能通過閱讀代碼來掌握軟件的真實運行情況。 我們之所以應該把提高代碼可讀性作為第一要務，就是因為讀代碼的次數遠比寫代碼的次數多