Clean Code 代碼整潔之道 總結

代碼整潔

提高代碼質量，爲後期維護、升級奠定基礎

第一章

1. 編寫可讀的代碼

2. 關注細節

3. 變量名命名

4. 重視代碼整潔

5. 學會總結,回看之前寫過的代碼,多寫代碼

   why bad code

   時間不夠、思路不對、難實現

   稍後等於永不 LeBlanc

   Bjarne Stoystrup C++語言發明者
   代碼邏輯直截了當
   減少依賴關係，便於維護
   依據某種分層戰略完善錯誤處理代碼
   性能調至最優

   簡單代碼規則 Ron Jeffries

   1. 能通過所有測試
   2. 沒有重複代碼
   3. 提現系統中的全部設計理念
   4. 包括儘量少的實體，比如類、方法、函數等

   總結 減少重複代碼、提高表達力，提早構建簡單抽象。

   修改變量名、拆分過長的函數、消除重複代碼

第二章

1. 根據具體用處命名
2. 避免使用有歧義的變量名
3. 小心使用差別較小的名稱
4. 明確數據類型或者說是什麼用處
5. 命名儘量可讀可搜索
6. 把類和函數寫的儘量小
7. 用名詞/名稱短語來命名類
8. 方法名應該是動詞/動詞短語
9. 儘量用通用的一些名稱來表示
10. 相同單詞用於相同的目的
11. 使用計算機專業術語
12. 添加變量名所在的有意義的語境
13. 不管重構還是自己寫都需要重視命名，增加代碼可讀性

第三章 函數

1. 函數需要短小
2. 判斷函數能否在拆出一個函數來
3. 自頂向下讀代碼 向下規則
4. 函數名稱儘量具體、有描述性
5. 函數參數儘可能少
6. 函數參數較多時，應封裝成類
7. 全局變量和局部變量要區分好
8. 函數只做一件事
9. 抽離異常處理語句
10. 消除重複
11. 結構化編程 每一個代碼塊有一個入口和一個出口 只有一個return 循環沒有continue 和break 不能有goto
12. 可以先寫出整體邏輯代碼，不斷優化
13. 程序就像是故事

第四章 註釋

1. 註釋是你代碼編寫的失敗
2. 註釋很少去維護
3. 儘量少寫註釋
4. 源頭還會代碼太糟糕
5. 還是有一些必要的註釋（法律信息、信息的註釋、對意圖的解釋、出現某些特定的情況或者問題的註釋）
6. TODO 以後要寫的東西，現在還沒實現
7. 保證註釋的正確性
8. 刪除沒有意義的註釋
9. 日誌式註釋應做相應的刪除
10. 不要的代碼直接刪掉
11. 註釋信息太多
12. 註釋和相關代碼聯繫緊密
13. 代碼重構和註釋重構

第五章 格式

1. 保持良好的代碼格式，儘量使用相同的格式規則
2. 格式會影響之後代碼維護者
3. 大致的結構和框架要搭好
4. 空格和空行增加代碼閱讀性
5. 關聯緊密的代碼應該相互靠近
6. 不要把關係密切的概念放在不同的文件中
7. 變量聲明靠近使用位置（函數頂部）
8. 實體變量在類的頂部聲明
9. 空格可以強調字符或運算符

第6章 對象和數據結構

1. 對象內部的結構要隱藏不應該暴露出去
2. 以抽象的形態表述數據
3. 過程式代碼和麪向對象
4. 得墨忒耳定律
   每個單元對於其他的單元只能擁有有限的知識：只是與當前單元緊密聯繫的單元；
   每個單元只能和它的朋友交談：不能和陌生單元交談；
   只和自己直接的朋友交談。
5. 避免混雜的數據結構或對象
6. Active Record 類似flask-sqlalchemy

第7章 錯誤處理

1. 必要時需要寫異常處理代碼
2. 針對特定語句可能拋出異常的語句增加異常，結構清楚
3. 避免傳遞null值
4. 錯誤處理隔離看待，獨立於主要邏輯之外，增加代碼的可維護性

第8章 邊界

…

第9章 單元測試

1. 編寫測試代碼，用於測試
2. tdd測試驅動開發，單元測試，編寫生產代碼之前要編寫測試代碼
3. 編寫整潔的測試代碼，按照生產代碼規範來編寫
4. 維護代碼也是一個大工程，如果在編寫測試代碼是沒有規範化。
5. 測試可讀性，要求簡潔明瞭
6. 用於測試而非生產環境
7. 測試代碼可以對代碼的限制寬鬆一點，測試都需要斷言斷言斷言
8. 功能代碼分解測試，越小越好
9. 測試規則
   1. 快速
   2. 獨立
   3. 可重複
   4. 自足驗證
   5. 及時
10. 提高測試代碼的重視程度 非常重要

第10章 類

1. 類的封裝，包括變量和函數的私有性
2. 創建短小的類
3. 只有一條修改的理由，只做一件事
4. 類的內部實現內聚，變量被每個類中的方法所使用（儘量）
5. 增加抽象類以滿足多變量
6. 結構要清晰，關係要理順
7. 調整代碼之後還是需要做進一步的驗證、測試