代碼整潔總結筆記

命名

• 名副其實：

一眼就能看起是啥意思，避免拼音，1,2,3那種

• 做有意義的區分

customerInfo與customer就沒有區別，data與dataInfo也沒有區別

• 有意義能搜索的名字：

比如7數值很難找，MAX_APP_INDEX 就好找多了

• 不一樣非要用前綴:

m_之類的，看多了也是很容易忽略，變成廢料

• 接口與實現：

這個我是喜歡加前綴的，比如ICallBack

• 類名：

用名詞

• 方法名：

用動詞

• 同類型命名：

可以約定一個前綴，方便查找分類

函數

• 短小：

能短小就儘量短小，越短小越容易看得懂

• 一個方法做一件事：

單一職責原則最好

• 避免多參數：

建議最好不要超三個參數，參數越少越好，多個參數可以封裝爲一個參數對象傳遞

• 避免標識參數參數：

參數傳入boolean進行判斷，其實可以轉爲兩個方法

• 使用異常代替返回錯誤碼：

如果主流程的多個步驟，這些步驟方法有對應的錯誤碼，這些錯誤碼決定了它下一步的執行，那樣主流程就有多個if判斷嵌套。可以通過異常代替錯誤碼，主流程一個try catch就行
這個我是保留意見的，我覺得出現這種代碼的概率很小，畢竟不同錯誤碼決定不同的結果，無法統一處理異常

• 避免重複代碼

重複代碼可以提取方法，這樣好處就是可以統一修改不用多個維護，並且減小代碼量

• 如何寫

不用糾結，可以開始隨心寫，寫完花點心思整理下代碼就行，記得養成這個習慣

類

• 遵循約定

類開始應該是變量列表，公共靜態常量最先出現

• 單一職責

類應該單一職責，不應該多參雜

糟糕的代碼

• 重複代碼
• 過長的函數，函數越短越好
• 過大的類

1.多的變量可以將關聯的提到新對象
2.去掉重複代碼
3.數據與ui分類，mvp架構
4.先確定流程與行爲，再編寫接口，再寫對應的實現

• 過多的參數
• switch使用過多
• 數據各處放，沒有統一
• 冗餘類（通過內部類解決）
• 過渡設計，覺得以後會用到
• 過多的註釋

複雜功能代碼設計

• 先設計，把流程圖整理清楚、合理、完善
• 面向接口編程