Clean Code Rule:
有意義的命名
1. 名副其實，能夠通過名稱知道變量、方法的作用意義;
2. 避免誤導，避免留下掩藏代碼本意的錯誤線索;
3. 做有意義的區分;
4. 使用讀的出來的名稱;
5. 使用可搜索的名稱;
6. 避免使用編碼，把類型或作用域編進名稱里面，徒然增加了解碼的負擔;
7. 避免思維映射，不應當讓讀者在腦中把你的名稱翻譯為他們熟知的名稱;
8. 每個概念對應一個詞，給每個抽象概念選一個詞，并且一以貫之;
9. 添加有意義的語境，用有良好命名的類、函數或命名空間來放置名稱。
函數
1. 短小，函數的第一規則是要短小;
2. 只做一件事;
3. 每個函數一個抽象層級，函數中的語句都要在同一抽象層級上;
4. 使用描述性的名稱，命名方式要保持一致;
5. 函數參數，最理想的參數數量是零， 我們不太期望信息通過參數輸出;
6. 無副作用，不做預期以外的行為;
7. 分隔指令與查詢，函數要么做什么事，要么回答什么事，但二者不可得兼;
8. 使用異常替代錯誤返回碼，錯誤處理代碼就能從主路徑中分離出來;
9. 別重復自己，重復可能是軟件中一切邪惡的根源;
10. 結構化編程，每個代碼塊盡量做到一個入口、一個出口。
注釋
1. 注釋不能美化糟糕的代碼;
2. 用代碼來闡述，很多時候，簡單到只需要創建一個描述與注釋所言同一事物的函數即可。
格式
1. 垂直格式，變量和函數應該在靠近被使用的地方定義;
2. 橫向格式，遵循無需拖動滾動條到右邊的原則。
面向對象設計的原則（SOLID）
1. 單一職責原則（SRP），就一個類而言，應該僅有一個引起它變化的原因;
2. 開放-封閉原則（OCP），軟件實體（類、模塊、函數等）應該是可以擴展的，但是不可修改;
3. Liskov替換原則（LSP），子類型必須能夠替換掉他們的基類型;
4. 依賴倒置原則（DIP），抽象不應該依賴于細節，細節應該依賴于抽象;
5. 接口隔離原則（ISP），不應該強迫客戶依賴于他們不用的方法，接口屬于客戶，不屬于它們所在的類層次結構。
單元測試（必需）
1. 保持測試代碼的整潔，和產品代碼一致的質量要求;
2. 每個測試Case只測試一個場景;
3. 整潔的測試遵循F.I.R.S.T.規則：
a. 快速（Fast），測試應該能夠快;
b. 獨立（Independent），測試應該互相獨立;
c. 可重復（Repeatable），測試應當在任何環境中重復通過;
d. 自足驗證（Self-Validating），測試應該有布爾值輸出表述通過或失敗;
e. 及時（Timely），測試應及時編寫。
迭代
1. 通過迭代設計達到整潔目的；
2. 提倡頻繁的檢入代碼和UT；
3. 鼓勵按TDD方式寫UT，TDD三原則：
a. 在編寫失敗的單元測試之前，不可編寫相應的產品代碼；
b. 單元測試做到剛好失敗或編譯錯誤，不做額外編寫；
c. 產品代碼剛好足以通過當前失敗的測試，不做額外編寫。
滬ICP050146651號-2
上海市互聯網違法與違規信息登記中心
