勒布朗（LeBlanc）法則：稍后等于永不（Later equals never）。
代碼混亂的代價：
隨著混亂的增加，團隊生產力也持續下降，趨向于零。當生產力下降時，管理層就只有一件事可做了：增加
更多人手到項目中，期望提升生產力。可是新人并不熟悉系統的設計。他們搞不清楚什么樣的修改符合設計意圖，
什么樣的修改違背設計意圖。而且，他們以及團隊中的其他人都背負著提升生產力的可怕壓力。于是，他們制造
更多的混亂，驅動生產力向零那端不斷下降。
image.png
- 《C++程序設計語言》）一書作者，Bjarne
我喜歡優雅和高效的代碼。代碼邏輯應當直截了當，叫缺陷難以隱藏；盡量減少依賴關系，
使之便于維護；依據某種分層戰略完善錯誤處理代碼；性能調至最優，省得引誘別人做沒規矩的
優化，搞出一堆混亂來。整潔的代碼只做好一件事。
Bjarne 也提到完善錯誤處理代碼。往深處說就是在細節上花心思。敷衍了事的錯誤處理代碼，只是程序員忽視細節的一種表現。此外還有內存泄漏，還有競態條件代碼。還有前后不一致的命名方式。結果就是凸現出整潔代碼對細節的重視。
糟糕的代碼引發混亂！別人修改糟糕的代碼時，往往會越改越爛。
減少重復代碼，提高表達力，提早構建簡單抽象
命名規則：
名副其實、見名知意
避免誤導
做有意義的區分
使用讀的出來的名稱
使用可搜索的名稱
避免使用編碼
避免思維映射
類名
方法名
別扮可愛
每個概念對應一個詞
別用雙關語
使用解決方案領域名稱
使用源自所涉問題領域的名稱
添加有意義的語境
不要添加沒用的語境
函數：
函數的第一規則是要短小，第二規則是還要更短小
只做一件事
每個函數一個抽象層級
switch語句
使用描述性名稱
函數參數
無副作用
分割指令與詢問
使用異常替代返回錯誤碼
別重復自己
結構化編程
