[筆記] Clean Code 無瑕的程式碼

Chap2.命名
1. 匈牙利命名法: 在有 IDE 的環境下不需要
2. 型別不應出現在名稱中。ex: AccountList、EmptyString
3. 介面名稱不須編碼,要就在實作編碼。ex: ObjectImp
4. 類別以名詞命名;方法以小寫動詞命名
5. 一個好名字通常表達的是「甚麼」(what),而不是「如何」(how)
6. 用靜態工廠方法取代多載建構子。ex: Complex com = Complex.FromRealNumber(23.0); //取代new
7. 不要在名稱加前綴 (否則 IDE 的提示會帶出所有此前綴的名稱)

Chap3.函式
1. 函式內容要簡短 (不要超過五行)
2. 函式名稱要明確、只做一件事情、以動詞開頭 (函數名稱長沒關係,不要縮寫;變數名稱長度10~16字元為佳)
3. 每個函式只有一層概念、相同層級的函式應置放在同一區塊 (上抽象下細節,由上而下閱讀程式碼)
4. switch 應搭配多型 (開放封閉原則)
5. 函式的參數不超過3個,以 this 取代輸出型參數 (輸出型參數:傳入一個類別並且有副作用的參數)
6. 指令和查詢分離 ( checkAndSet() 改為 check(){set();} )
7. try/catch 的 try 應該在一個函式的開頭,有多層的 try/catch 應該將內層 try/catch 抽取出來

Chap4.註解
1. 不要替糟糕的程式碼寫註解─重寫它
2. 在重要的步驟寫註解提醒
3. 不要把程式碼註解掉,直接刪掉,改以 source control 找回舊程式碼

Chap5.編排
1. 遵循團隊一致的 coding style

Chap6.物件及資料結構
1. 善用多型 (物件導向) 取代程序式的程式結構
2. The Law of Demeter: 每一行程式只能呼叫一次方法。這個方法來自:1.該物件本身、2.傳入該函式的參數、3.在該函式中所產生的物件、4.該物件的資料成員
3. 以 DTO/POJO/JavaBean 傳遞資料

Chap7.錯誤處理
1. 不要用 enum ERROR_CODE,改用 try/catch
2. finally {} 後面就不要再寫程式碼了
3. 不要在應用程式寫 Unchecked Exception 的捕捉,只能寫在重要函式庫
4. 用一個類別包裹 (Wrap) 第三方API,隔離應用程式直接依賴 API
5. 程式不要傳遞 null 參數,因為一般人都不會對 null 參數寫錯誤處理

Chap8.邊界
1. 把 log4j 包裹成自己的 LogTest class,作者是用來 TDD。可以針對不同用途發展其他 Log class

Chap9.單元測試
1. 一個測試只測一個概念 (DRY法則)
2. 寫測試的法則是 F.I.R.S.T (快速、獨立、可重複性、自我驗證、及時)

Chap10.類別
1. 保持凝聚性(單一職責)會得到許多小類別 (有利發展開放封閉原則)

Chap11.系統
1. 此章節探討AOP、Proxy、工廠模式,模組化關注點

Chap12.羽化
1. 四個原則: 執行完所有的測試,沒有重複的部分,表達程式員的本意,最小化類別和方法的數量(?)
2. 此章以 Kent Beck 程式示範上述原則,與相依注入 (DI) 重構技巧

 

自己補充:
1.繼承與包含 ─from 軟體建構之道(第二版)
如果多個類別共享資料而非行為,應該建立這些類別可以包含的共用物件。
如果多個類別共享行為而非資料,應該讓它們從共同的抽象類別繼承而來,並在抽象類別裡定義共用的方法。 (對介面寫程式)
如果多個類別既共享資料也共享行為,應該讓它們從共同的抽象類別繼承而來,並在抽象類別裡定義共用的物件和方法。
當你想由抽象類別控制方法時,使用繼承;當你想自己控制方法時,使用包含。

其他人的補充:
http://ihower.tw/blog/archives/1960

廣告
發表留言

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s

%d 位部落客按了讚: