1. 應用程式級別代碼壞味道
1.1. 布爾盲點
-
1.1.1. 由于函式使用布林值而導致的資訊缺失
-
1.1.2. 解決方案是將布爾替換為列舉型別
1.2. 組合爆炸
-
1.2.1. 不同的代碼使用不同的引陣列合來執行同一件事情的產物
-
1.2.2. 解決方案使用泛型
1.3. 人為復雜性
-
1.3.1. 簡單的架構復雜化
-
1.3.2. 解決方案務必保持軟體的簡單易懂（Keep It Simple，Stupid，KISS）
1.4. 資料泥團
-
1.4.1. 相同的欄位同時出現在不同的類和引數串列中時
-
1.4.1.1. 說明系統中缺少類定義
-
1.4.2. 識別并泛化缺失的類可以降低系統的復雜度
1.5. 粉飾注釋
- 1.5.1. 注釋中用優美的詞句掩蓋代碼的缺點
1.6. 重復代碼
-
1.6.1. 多次出現的代碼
-
1.6.1.1. bug=技術債務=程式員支出
-
1.6.2. 解決方案將這些代碼添加到當前專案的可重用類并放置在類別庫中
-
1.6.3. 解決方案2：面向方面編程（AOP）是另一種洗掉樣板代碼的方法
1.7. 意圖不明
- 1.7.1. 他人無法輕易理解代碼的意圖
1.8. 可變的變數
-
1.8.1. 不同操作之間多次更改的變數
-
1.8.2. 消除變數的可變性，使其值更易于預測
-
1.8.3. 函式編程
-
1.8.3.1. LINQ
1.9. 怪異的解決方案
-
1.9.1. 源代碼中解決同樣問題的方案多種多樣
-
1.9.1.1. 源代碼中解決同樣問題的方案多種多樣
-
1.9.1.2. 沒有制定統一標準而造成
-
1.9.1.3. 程式員并沒有意識到系統中已經存在解決方案
-
1.9.2. 解決方案：不同的重復的解決方案撰寫新類，并將最整潔最高效的方式添加到類中
-
1.9.3. 解決方案2：配接器模式來統一不同的系統介面
1.10. 霰彈式修改
-
1.10.1. 一種改動需要在多個類中進行修改
-
1.10.1.1. 復雜的代碼還會導致程式員認知負擔過重
-
1.10.2. 減少耦合可以使類更易于測驗
-
1.10.3. 將不屬于類的代碼移出到恰當的位置可以提高應用程式的可讀性、可維護性與可擴展性
1.11. 解決方案蔓延
-
1.11.1. 一種職責在不同的方法、類甚至庫中均被實作
-
1.11.2. 單一職責轉移到同一個類中
1.12. 不可控的副作用
-
1.12.1. 在產品中由于無法被質量保證程序發現而引起的問題
-
1.12.2. 唯一的辦法就是重構代碼使其完全可測，并可以在除錯期間查看變數的狀態以確保程式的正確性，
2. 類級別代碼壞味道
2.1. 過高的圈復雜度
-
2.1.1. 大量的分支和回圈
-
2.1.2. 1～10
-
2.1.2.1. 代碼簡單沒有風險
-
2.1.3. 11～20
-
2.1.3.1. 較復雜，風險相對較低
-
2.1.4. 21～50
-
2.1.4.1. 引起注意，中等風險
-
2.1.5. 超過50
-
2.1.5.1. 風險高，必須重構
-
2.1.6. 解決方案
-
2.1.6.1. 使用工廠模式替換switch陳述句
-
2.1.6.2. 改善if陳述句條件檢測的可讀性
-
2.1.6.3. LINQ陳述句替換回圈
2.2. 發散式變化
-
2.2.1. 對代碼進行一處更改，但是發現自己必須更改許多不相關的方法
-
2.2.2. 原因
-
2.2.2.1. 類結構不良造成
-
2.2.2.2. 復制粘貼代碼
-
2.2.2.3. 利用基類和子類的關系實作繼承
2.3. 向下型別轉換
- 2.3.1. 將基類轉換為它的一個子類
2.4. 過度的字面量使用
-
2.4.1. 將字面量保存在常量中
-
2.4.2. 將字串字面量放置在本地化資源檔案中
2.5. 依戀情結
- 2.5.1. 當一個方法花費大量的時間處理類中的代碼而非自身的代碼
2.6. 狎昵（xiá nì）關系
-
2.6.1. 一個類若依賴另一個類的實作細節
-
2.6.2. 類之間不應當相互依賴
-
2.6.3. 類應當是自包含的
-
2.6.4. 類之間應該盡可能少地互相了解彼此的底細
2.7. 不恰當的暴露
-
2.7.1. 類暴露了其內部細節
-
2.7.2. 打破了面向物件編程的封裝原則
2.8. 巨大的類
- 2.8.1. 務必令其盡可能小巧、整潔、易于閱讀
2.9. 冗贅類
-
2.9.1. 一種并不包含什么有效操作的類
-
2.9.2. 和其他包含相似意圖的類合并
-
2.9.3. 削減繼承層次結構
-
2.9.3.1. 理想的繼承層次是1
-
2.9.4. 非常小的類還可以考慮采用行內的處理方法
2.10. 中間人類
-
2.10.1. 僅將功能委托給其他物件
-
2.10.2. 舍棄中間人直接和處理相應職責的類進行互動
-
2.10.3. 將其與現有類合并
2.11. 孤立的變數和常量類
-
2.11.1. 使用一個獨立的類來定義系統不同部分使用的變數和常量
-
2.11.2. 丟失其背景關系而無法表達任何實際含義
-
2.11.3. 移動到使用它們的位置
2.12. 基本型別偏執
-
2.12.1. 使用常量作為欄位名稱
-
2.12.2. 不恰當地使用常量保存資訊
-
2.12.3. 使用基本型別值而非使用物件
2.13. 被拒絕的遺贈
-
2.13.1. 一個類繼承自另一個類，卻沒有使用其所有方法
-
2.13.2. 考慮是否真的需要基類
2.14. 夸夸其談未來性
-
2.14.1. 一個類的功能現在不需要，但是將來可能用到
-
2.14.2. 死代碼，應當將其洗掉
2.15. 命令，而非詢問
-
2.15.1. 將資料和操作資料的方法系結在一起
-
2.15.2. 一個物件包含邏輯，并要求其他包含資料的物件提供資料以供其執行操作，則應當將邏輯與資料合并到一個類中
2.16. 臨時欄位
-
2.16.1. 不需要在物件的整個生命周期記憶體在的成員變數
-
2.16.2. 將臨時欄位及操作這些欄位的方法移動到它們自己的類中
3. 方法級別的代碼壞味道
3.1. 不合群的方法
-
3.1.1. 一個類中和其他方法截然不同的方法
-
3.1.2. 考慮該方法的目的
-
3.1.2.1. 確定哪里才是該方法最合適的落腳點了
3.2. 無用的代碼
-
3.2.1. 現存的方法無人使用
-
3.2.2. 要識別無用的代碼并將其洗掉
-
3.2.3. 構造器、屬性和變數也應遵循相同的原則
3.3. 過多的回傳資料
- 3.3.1. 遠超客戶端的呼叫
3.4. 過長或過短的識別符號
- 3.4.1. 識別符號應當既能描述物件又簡明扼要
3.5. 過長的代碼行
- 3.5.1. 應盡量將其格式化，在點號和逗號處換行
3.6. 過長的方法
- 3.6.1. 方法應當只負責執行單一任務
3.7. 引數過多
- 3.7.1. 方法引數數目超過3個
3.8. 過度耦合的訊息鏈
-
3.8.1. 當一個方法呼叫一個物件，繼而呼叫另一個物件
-
3.8.2. 訊息鏈違反了迪米特法則
-
3.8.2.1. 類只應當和離其最近的鄰居通信
-
3.8.2.2. 重構類，將所需的狀態和行為放在距離其更近的位置
3.9. 過高的圈復雜度
3.10. 人為復雜性
3.11. 依戀情結
3.12. 狎昵關系
3.13. 冗贅方法
3.14. 中間人方法
3.15. 怪異的解決方案
3.16. 夸夸其談未來性
3.17. 參見前文
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/547860.html
標籤：C#