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