clean code 理解

- 3月 15, 2021

這篇文章是取自 wojteklu " Clean Code summary "．閱讀完這篇文章後，稍微用自身的理解翻譯成中文．由於本身沒有閱讀過這一本書，所以理解上可能會點有出入．但如果你對哪一點特別有感覺，就留言分享出來，讓大家來討論吧．

Clean Code 作者 Robert C. Martin

前言

如果程式碼可以讓團隊中的每個人都能理解，那麼它就是整潔的．除了原始作者外，其他開發人員也可以閱讀和改進程式碼．當中的理解，包含可讀, 可修改, 可擴充, 及可維護性．

General rules ( 一般規則 )

1. 遵循每種語言的基本規定．

2. 讓程式碼保持簡單，盡可能降低複雜度．

3. 當程式碼有問題，無論是否為你處理的部分．將它清理乾淨，有意地為下一個維護者改善程式中的問題．

不太清楚此處描述是否與作者表達的相同，畢竟這太大愛了！

4. 找到問題的根本原因．

在修復 Bug 時，如果只是做了表面的處理．那麼僅僅是修正了當前的問題．當其它的操作或隨著時間的流逝，可能會造成額外的問題．因此處理時應該找到問題的根源．

Design rules ( 設計規則 )

1. 讓專案中的資料結構可以包持高度的擴充性．

避免新增或刪除某項數據時，需要翻新專案的架構．

2. 使用 if / else 或 switch - case，有效地區別不同條件的執行

3. 將程式碼多執行緒的部份分離

方便查看及追蹤問題．

4. 防止過度配置

此處不確定是否為避免加入太多限制，比如說系統版本，或硬體最低支援等，會導致專案執行時會有很多限制．

5. 使用依賴

有人已經寫好套件，就避免重複在自己製作一個．

6. Law of Demeter

Law of Demeter

Understandability tips ( 易懂的提示 )

1. 保持一制性，如果有使用某種規則，就可以相同的方式執行

比如說取得字串是透過Ａ方式，使用固定規則，而不是一個地方使用Ａ，其它使用 B，會讓維護的人難以理解．

2. 對變數優先使用對應的類型，而不是 Default 預設值

Name rules ( 命名規則 )

1. 選擇描述性和明確的名稱

2. 做出有意義的區別

3. 使用明顯的名稱

4. 使用可搜索的名稱

5. 將數字的部分命名成變數

否則看到一串數字無法馬上理解．

6. 避免添加前綴或類型的相關訊息

Function rules ( 方法命名 )

1. 小

2. 只做一件事

3. 使用描述性的名稱

4. 讓傳進的參數盡可能減少

5. 沒有副作用

不確定其中的意思．

6. 避免使用 Flag 將 function 內容切開，將 function 拆開獨立使用，方便在沒有這些 Flag 時，其他人可以使用

Comments rules ( 註解規則 )

1. 程式碼說明

2. 使用後應該注意的事項

3. 不要註解掉沒有使用的程式碼，刪除即可

Source code Structure (程式碼結構)

1. 不要破壞程式碼縮排

2. 相關程式碼應該再垂直方向上密集顯示

避免在搜尋時要不斷滾動滑鼠來搜尋．