clean code 理解

這篇文章是取自 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. 保持一制性,如果有使用某種規則,就可以相同的方式執行

比如說取得字串是透過 A 方式,使用固定規則,而不是一個地方使用 A,其它使用 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. 相關程式碼應該再垂直方向上密集顯示

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

3. 定義變數,確認符合正確的使用


Tests ( 測試 )

1. 易讀

2. 獨立的

3. 快速

4. 可重複


Code smells (程式碼內不好的氣味)

1. 剛性 : 軟體難以更改,改動會連動很多部分,需要一同修改

2. 脆弱 : 易碎性,改動一處造成程式多處損壞

3. 固定 : 程式碼沒有彈性,造成其他專案或功能沒有辦法通用

4. 不必要的複雜性

5. 不必要的重複

6. 不透明,程式碼很難理解


後記

如果這篇文章對於你有幫助,可以幫忙分享給更多的人.文章內容如果有誤,可以在下方留言告知.本網站主要提供程式相關資訊,想獲得最即時的資訊,可以訂閱透過 email 閱讀.

留言

熱門文章

2021申請 Android Developer 開發者帳號及上架步驟

Generate Signed Bundle / APK(s) & Bundle Tool 基本使用 & .aab安裝方式

40 個可以改變寫程式技巧的秘訣