文檔說明

《代碼整潔之道》是2009年12月由人民郵電出版社出版的圖書，作者是馬丁。本文僅分享閱讀之后的收獲。有興趣的請詳細閱讀原著。

代碼簡潔

有意義的命名

• 類的命名
  能夠凸顯出所屬領域，比如說XXXContorller，XXXService,XXXUtils,XXXHandler等，一般 我們經常取業務相關的名稱，并以該類所屬領域來命名類名

• 方法的命名
  能夠凸顯出方法的作用，比如saveXXX(),updateXXX(),doXXX()等，一般我們經常以作用為前綴再加上業務相關的名稱來命名方法名

• 屬性的命名
  屬性的命名，盡可能可以包含業務名稱，比如登錄狀態屬性，有的同學可能喜歡簡單風格直接用status，我個人更傾向與帶上業務表示loginStatus這樣子

只做一件事

• 類層次
  DDD領域驅動現在在技術圈一直是個很熱門的話題。如果類的作用邊界上下文定義在自己的專屬領域，那么我愿稱之為專一的類。
  常見的一般有負責業務，負責存儲的，負責提供輔助的等，不同的類應該劃分在自己專屬的領域

• 方法層次
  如果說類需要在領域層面專注于一件事，那么方法則是需要將一個領域的某一道工序，盡可能分解組合，已達到方法的復用，解耦和內聚

結構化編程

僅從原著中摘出一句分享:
每個函數、函數中的每個代碼塊都應該有一個入口、一個出口，遵循這些規則，意味著在每一個函數中只該有一個return語句，循環中不能有break或continue語句，而且永永遠遠不能有任何goto語句

有效且優雅的注釋

• 業務解釋
  類一般可以簡介下它所屬的領域即可
  方法一般需要簡介下它處理的業務，如果業務流程復雜且長，建議簡單描述下處理流程
• TODO標記
  主要記錄未完成或待完善的事項
• 使用警示
  常常對于一些公用的方法，如果有必要可以備注下使用需要注意的事項，這對其他同學使用應該會非常友好

代碼格式化

代碼格式化，現在基本編寫工具都有，SQL代碼的格式化也需要注意下吧。

得墨忒耳律

暴露抽象接口，隱藏實現，詳細可自行查詢資料。

錯誤處理

• 抽離try catch代碼塊
  try catch包裹的代碼塊用方法抽離，這樣看起來會簡潔舒服很多
• catch處理
  有的同學打印錯誤日志，直接返回null或者錯誤代碼
  有的同學拋出業務異常（也是書中推薦的方式）
  個人傾向于后者

類瘦身

曾見到過，一個類上百個屬性。。。
尤其Controller查詢參數VO,有的同學crud一個VO搞定，可能是為了趕時間吧
在某些場景下繼承、組合也許是不錯的選擇

寫在最后

相互學習，提升自己。每個人心中對簡潔的定義或許并不相同，歡迎大家評論，愿與諸君共勉

總結

以上是生活随笔為你收集整理的代码整洁之道—技术分享的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。