《代碼整潔之道》讀書筆記

《代碼整潔之道》讀書筆記
版權聲明：歡迎轉載，共同進步。請註明出處：
轉自：http://blog.csdn.net/puppet_master https://blog.csdn.net/puppet_master/article/details/76356049
1.重複是一切邪惡的根源，許多原則與設計規則都是爲了避免重複而產生的。如面向對象編程的基類，面向組件編程等等。
2.添加有意義的語境，對於命名，起一個比較容易檢查的命名。比如都在一個工程裏面，就沒有必要爲所有類增加一個相同的前綴了，否則當你搜索的時候，所有的東西就都會出來了。。。。
3.函數應該只做一件事，做好這件事，只做這一件事。而且要儘可能短小，讓人一眼能從函數名字看出這個函數要幹什麼。
4.對於代碼結構，最好是一個自頂向下的規則，方便我們閱讀代碼。比如上面依賴下面，先看上面，看完後向下依次看依賴項。A函數調用B函數，B函數調用C函數，那麼最好的順序就是ABC，而且距離最好不要太遠，否則當我們看的時候就需要跳來跳去。如果兩個函數是概念相關的，那更應該放在一起。
5.儘量避免多參數的函數，最好是兩個以下。除非有足夠的理由，才用3個以上參數的函數。
6.標識參數會讓函數醜陋不堪，爲true的時候做A，false的時候做B，相當於宣佈了這個函數做兩件事。
7.函數要麼做什麼事，要麼回答什麼事，二者不可兼得。一般是set設置某些狀態，get或is返回某些狀態。
8.並不是一開始就能寫出短小精悍的函數，一開始函數都是比較冗長複雜的，需要打磨這些代碼，讓其逐漸整潔。
9.別給糟糕的代碼加註釋，重新寫吧！如果代碼本身有足夠的表達力，那根本不需要註釋。註釋是彌補我們不能用代碼表達我們意圖的補救手段。
10.好的註釋：文件頭法律信息，提供信息的註釋，對意圖的解釋，某些無法修改庫文件等的返回值或參數的解釋，警示，TODO註釋
11.壞註釋：喃喃自語，無用的註釋（讀註釋比代碼時間還長），誤導性註釋，日誌式註釋（文件開頭的修改日誌，有svn了，貌似不需要了），大括號後面標註括號的註釋（說明函數太長），註釋掉的代碼（有svn）
12.過程式代碼便於在不改動既有數據結構的前提下增加新函數；面向對象代碼便於在不改動現有函數的情況下增加新的類。
13.得墨忒耳律：模塊不應該瞭解他所操作內部對象的結構。比如a->b.c += d應該把b.c+d風風裝到b的一個方法e，直接調用a->e就好了。
14.錯誤處理很重要，但是如果它搞亂了代碼邏輯，就是錯誤的做法。
15.特例模式：創建一個類或配置一個對象，用來處理特例，將異常處理封裝到特例對象中，客戶端代碼就不需要進行異常處理了。
16.儘量不要返回null值，也儘量不要把null作爲參數傳遞給函數。
17.邊界：當我們拿到一個庫時，我們可以進行一定的封裝，不直接使用庫內函數，而是調用自己的接口，這樣在庫更新時非常容易替換。我們只需要把庫當成一個黑盒子。
18.測試：F（快速），I（獨立），R（可重複），S（自足驗證），T（及時）
19.類要儘可能短小，如果名字不好起或者不能很好地用一句話說明這個類是幹什麼的，那就說明這個類可能有些大了。單一職責原則
20.依賴倒置原則：類應當依賴於抽象而不是具體實現。
21.將構造和使用分開，可以初始化在main中進行構造，也可以使用工廠。
22.無論是在設計系統還是單獨的模塊，別忘了使用大概可工作的最簡單方案。
23.簡單設計的四條原則（總要度遞減）：運行所有測試；不可重複；表達程序員的意圖；儘可能減少類和方法的數量。
24.優秀的軟件設計大都關乎分隔-創建合適的空間放置不同種類的代碼，對關注面的分隔讓代碼更容易理解和維護。
25.代碼在我們離開時要比來時更整潔。
26.一些需要重構的內容：
1）註釋：不恰當的信息，廢棄註釋，廢棄代碼，冗餘註釋
2）環境：儘可能容易構建，儘可能容易測試
3）函數：過多參數，輸出參數，標識參數（選擇算子參數），死函數
4）明顯的行爲未被實現：類名或者函數名應當符合知覺，否則就需要使用的人詳細讀代碼細節。
5）注意不正確的邊界行爲：不要依賴知覺，需要對各種邊界條件進行判斷處理。
6）注意警告：不要忽視這些告訴我們可能存在隱患的忠言。
7）注意重複：有重複說明我們遺漏了抽象；重複是萬惡之源。
8）基類不要依賴於派生類：基類要對派生類一無所知。
9）刪除死代碼：根本不可能執行的代碼不要留情面。對於沒用的註釋，變量，統統幹掉。
10）垂直分隔：變量和函數使用和定義儘量不要太遠，私有函數最好在首次使用它的函數下面定義。
11）注意前後一致：一些命名，使用等統一用一套規則，利於閱讀和修改。
12）不要人爲耦合：比如一些外部的enum，放到類中，就無形造成了其他類和該類耦合。
13）特性依戀：類的方法儘量只對勒種的變量和函數感興趣，不要垂青其他類中的變量和函數。（只能說是儘量吧）
14）不要太晦澀：有可能我們寫得很專業，但是給看得人需要花很久才能理解。
15）斟酌變量或內容的位置：遵循最小驚異原則，放在最符合人類知覺的地方。
16）注意靜態方法：如果靜態方法有多重表現，是否考慮是不是需要有多態，改爲非靜態實現。
17）使用解釋性變量：讓程序可讀的最有效方法之一就是將計算過程使用的中間值全都改成有意義的命名。
18）函數名稱表達其行爲：如果必須查詢函數實現或者文檔才能弄明白函數是幹什麼的，就說明函數應該改個名字了。
19）理解算法：在真正完成函數之前，我們必須理解這個函數是怎麼工作的，而且還要驗證這種解決方案是否正確。
20）邏輯依賴改爲物理依賴：原始數據和業務邏輯的依賴關係最好改爲函數方法和業務邏輯之間的依賴關係。
21）用多態替代if/else或switch/case：優先考慮多態實現。
22）團隊開發儘量使用同一套規則。
23）用命名常量代替魔術：一些數字最好使用命名常量來代替，否則難以修改與理解。
24）準確：消除代碼中含糊和不準確的內容，明確自己爲什麼這麼做。
25）結構基於約定：基類強制派生類實現抽象方法會比switch更加讓人遵守這個約定。
26）封裝條件：一些if語句進行判斷，但是不好理解，可以直接將這個判斷條件寫成一個函數，判斷時使用這個函數，方便理解。
27）避免否定條件：使用！判斷沒有肯定判斷直白。
28）函數只做一件事。
29）掩蔽時序耦合：有些需要按照順序初始化的，可以按照上一個作爲下一個的輸入。防止其他人誤用。
30）別隨意：結構太隨意或者位置太隨意可能會讓人誤用。
31）封裝邊界條件：把處理邊界條件的代碼集中到一處，比如+1，-1等。
32）得墨忒定律：編寫害羞的代碼，只讓其直接協作者瞭解內部。不要暴露給再上層。
33）不要繼承常量：把常量放在繼承樹最頂層並不是個好選擇。不如靜態導入。
34）名稱作用域越大，名稱就應該越長，越準確。
35）避免編碼：現代編程環境不是很需要m_，f_等前綴。
36）名稱說明副作用：比如獲得一個物體，不存在就創建，用GetOrCreate就比Get容易理解。