命名
一眼就能看起是啥意思,避免拼音,1,2,3那種
customerInfo與customer就沒有區別,data與dataInfo也沒有區別
比如7數值很難找,MAX_APP_INDEX 就好找多了
m_之類的,看多了也是很容易忽略,變成廢料
這個我是喜歡加前綴的,比如ICallBack
用名詞
用動詞
可以約定一個前綴,方便查找分類
函數
能短小就儘量短小,越短小越容易看得懂
單一職責原則最好
建議最好不要超三個參數,參數越少越好,多個參數可以封裝爲一個參數對象傳遞
參數傳入boolean進行判斷,其實可以轉爲兩個方法
如果主流程的多個步驟,這些步驟方法有對應的錯誤碼,這些錯誤碼決定了它下一步的執行,那樣主流程就有多個if判斷嵌套。可以通過異常代替錯誤碼,主流程一個try catch就行
這個我是保留意見的,我覺得出現這種代碼的概率很小,畢竟不同錯誤碼決定不同的結果,無法統一處理異常
重複代碼可以提取方法,這樣好處就是可以統一修改不用多個維護,並且減小代碼量
不用糾結,可以開始隨心寫,寫完花點心思整理下代碼就行,記得養成這個習慣
類
類開始應該是變量列表,公共靜態常量最先出現
類應該單一職責,不應該多參雜
糟糕的代碼
1.多的變量可以將關聯的提到新對象
2.去掉重複代碼
3.數據與ui分類,mvp架構
4.先確定流程與行爲,再編寫接口,再寫對應的實現
- 過多的參數
- switch使用過多
- 數據各處放,沒有統一
- 冗餘類(通過內部類解決)
- 過渡設計,覺得以後會用到
- 過多的註釋
複雜功能代碼設計
- 先設計,把流程圖整理清楚、合理、完善
- 面向接口編程