###### tags: `CleanCode`
<STYLE>
p,li,oi,h3{
font-family:"微軟正黑體";
}
</STYLE>
# 基本觀念

特點:
> 戴夫.湯馬斯(Dave Thomas)；羅恩.傑佛瑞(Ron Jeffries)
* ==充分表達系統設計的構思，使用有意義的名稱，增加程式的**可讀性**==
* ==單一職責原則，一個類別應該只有一個職責==
:::info
<h2>沒有重複的程式碼!必須盡可能減少程式碼的相依性</h2>
:::
---

### 1️⃣命名

* 使用具有意義的名稱
* 選擇能反映出類別或函式的抽象層次之名稱
* 避免使用常見字詞(ex:hp、sco..)
* 避免使用與變數型態無相關的相近字詞(ex:accountList)
* 要區別相似功能的function，需使用能辨識其不同處的命名
* 相同概念使用同一字詞
* 單一字母或數字可用於小函式中，其餘盡量使用可被搜尋的名稱(ex:用sum取代s)
* 不應該將型態編碼到名稱裡

**類別**：使用名詞or名詞片語，不該使用動詞；避免用Manager、Processor、Data、Info。
**方法**: 使用動詞or動詞片語。
> overload時，使用含參數資訊的方式。
> 例：將new Complex(23.0)改以Complex.FromRealNumber(23.0)方式產生，並考慮將後者建構子設為private
---
### 2️⃣函式
* 簡短、短小精幹，讓函式長度愈短愈好
* 每個函式都只做一件事
* *檢測方式：是否能從中提煉出另一個函式?且新函式不能只用來重新詮釋原函式的實作*
* 將例外處理(try/catch)提取成一個函式
#### ※注意事項
:::info
* 避免過多的參數：避免參數超過3個。
* 避免輸出型參數(在非物件導向程式設計可見)：函式盡量只能修改其所屬物件的狀態。
* 避免旗標參數(Flag)：表示此函式只做了不只一件事情，違反單一職責原則。
* 移除被遺棄的函式：刪除不會用到的函式(若要查找，請記住可以從原始碼管控系統查找)
:::
---

### 3️⃣註解
避免多餘的註解，會增加閱讀複雜度與誤導。
* 有益：提供函式的基本資訊、解釋某行程式之意圖、闡明參數與回傳值、待辦事項
* 有害：日誌型註解、干擾無益的註解
#### ※注意事項
:::info
* 註解應該保留技術性紀錄(ex:程式或設計方面的資訊)，歷史修改則不太適合放在此。
* 若發現註解過時，最好盡快更新或移除它。
* (1)如果程式碼已能表達意圖，則不需要多餘註解。(2)註解應該說明程式本身無法表達的意圖。
* 選用詞彙與正確的文法及符號，不說廢話。
* 移除被註解掉的程式碼
:::
---

### 4️⃣程式碼編排

* 垂直空白：不同概念間使用換行區隔
* 垂直密度：避免在函式裡使用多行註解
* 垂直距離：變數宣告應盡量靠近被使用的地方/概念相似的函式首要放在一起；而相依的函式在編排上則盡量次要靠近
* 水平空白：用於突出重要的元素。避免將高度相關的元素分開(ex:函式名與參數)。

---
肯特.貝克(Kent Beck)提出簡單設計的四原則，前三點是最為重要的守則。：
* 執行完所有的測試
* 程式重構(**禁止重複的程式碼**、**程式碼具表達力**、**最小化類別與方法的數量**)
#### 1. 執行完所有的測試
撰寫容易測試的程式，並且持續執行程式測試。讓程式碼保持低耦合度與高凝聚度。
#### 2. 禁止重複的程式碼
不論是完全相像或者看似相像的程式碼，都需要經過重構。甚至能將提取出來的方法移至另一個類別，遵守單一職責原則(SRP)。
#### 3. 程式碼具表達力
* 可以利用**選擇合適的名稱來命名類別或函式**
* 透過**讓函式和類別簡短化**，通常較容易撰寫、命名與理解。
* 利用**標準命名法**，(使用標準化名稱，如COMMAND或VISITOR，當作實作模式的類別名稱。)
#### 4.最小化類別及方法的數量
建議保持類別、函式，以及系統的簡短。