本文轉自Liter’s Blog
1.空指針異常
第一就要說這個，必須的，避免了它，大概意味着避免80、90%的錯誤吧，對方法的調用不進行空指針判斷而造成針異常（原則是千萬不要想當然認爲一個對象就不會空），舉個簡單例子就是equals操作時沒有將常量放在equals操作符的左邊（字符串變量與常量比較時，先寫常量可以避免空指針異常）。記得有危險的地方要麼if判斷要麼try catch。
2.命名與註釋
方法和變量命名隨意而不規範，沒有類註釋，方法註釋或者註釋不規範，代碼修改後，不同步修改註釋，註釋與代碼不符。
3.數據類重載
數據類不重載toString()方法，log打印時會對信息展示有所幫助。（說明：編程規範要求‘所有的數據類必須重載toString()方法，返回該類有意義的內容’）。
4.重量級資源釋放
數據庫操作，IO操作的資源沒有及時釋放，釋放順序不正確，或者使用沒有必要的預處理，數據庫操作，IO操作等需要使用結束close()的對象必須在try-catch-finally的finally中close()。
5.無視循環體效率
循環體內包含了大量沒有必要在循環中處理的語句，循環體內循環獲取數據庫連接，垂體內進行不必要的try-catch操作，（說明：編程規範中建議不要在循環體內調用同步方法和使用try-catch塊）。
6.小問題大傷害
不對數組下標作範圍校驗；用“==”比較兩個字符串內容相等；對list做foreach輪迴時，循環代碼中修改list的結構。
7.異常處理
字符串轉化爲數字豐數據庫時沒有做異常處理；捕捉異常後沒有在打印異常棧。
8.日誌
沒有打印異常棧消息，日誌沒有定位，沒有實際作用；日誌打印亂糟糟或者無意義；日誌和實際情形不一致。
9. 萬惡的魔鬼字符，魔鬼數字。
10. 可複用性低
差不多的功能，到處都是冗雜的看似不同的代碼（實際上很多可以抽離複用）。
* 建議1：碼塊/常量/資源可以集中公用的一定共用，即使共用邏輯複雜一點（防止邏輯太過複雜）也值得，修改起來很輕鬆，修改一種，到處有效。
* 建議2：充分利用繼承、多態、封裝等面向對象機制來提高可複用性
11.可讀性不高：
- a 代碼不分組，不合理使用空行，相似作用的函數沒有聚集在一塊；
- b 邏輯嵌套不優化，嵌套if else層級過多；
- c 代碼與數據耦合（常量或者SQL語句和邏輯耦合）；
（建議：設計從簡，遵循KIS原則；膽大兼顧心細，平衡穩定性和重構之間的矛盾，使代碼以至架構和模塊越來越合理）
12. 編程思想
模塊分離
舉個小例子，有不少同學在Activity裏做了很多事，甚至做了DAO、網絡操作、數據解析，這不是很合理的，導致一個UI和邏輯之間的‘門面’掛載了過多的傷不起的‘難以承受之重’，閱讀困難，邏輯龐大。（建議模塊和代碼遵循MVC模式，建議View視圖、控制相關（內存管理、核心邏輯），數據相關（文件操作、數據庫操作、網絡操作、數據組裝與解析、數據模型）各分一個相對獨立大、小模塊，模塊內分層級架構（積極合理使用繼承與實現等面向對象機制））。
單一職責
有的同學寫類啥都可以幹，管得了內存，控得住文件，做得了解析，搞得了組裝，上得了天堂，下得了廚房。這個是模塊分離的基礎。
接口隔離
舉個例子一個水果類在這裏是賣水果功能，在那裏卻還可以買水果，這樣是不太合理的，一個類對另一個類的依賴性建立在最小接口之上。一個接口一個角色，一種客戶一種接口。