編寫高質(zhì)量代碼：改善Java程序的151個建議

前言
第1章　Java開發(fā)中通用的方法和準則
建議1： 不要在常量和變量中出現(xiàn)易混淆的字母
建議2： 莫讓常量蛻變成變量
建議3： 三元操作符的類型務必一致
建議4： 避免帶有變長參數(shù)的方法重載
建議5： 別讓null值和空值威脅到變長方法
建議6： 覆寫變長方法也循規(guī)蹈矩
建議7： 警惕自增的陷阱
建議8： 不要讓舊語法困擾你
建議9： 少用靜態(tài)導入
建議10： 不要在本類中覆蓋靜態(tài)導入的變量和方法
建議11： 養(yǎng)成良好習慣，顯式聲明UID
建議12： 避免用序列化類在構造函數(shù)中為不變量賦值
建議13： 避免為final變量復雜賦值
建議14： 使用序列化類的私有方法巧妙解決部分屬性持久化問題
建議15： break萬萬不可忘
建議16： 易變業(yè)務使用腳本語言編寫
建議17： 慎用動態(tài)編譯
建議18： 避免instanceof非預期結(jié)果
建議19： 斷言絕對不是雞肋
建議20： 不要只替換一個類
第2章　基本類型
建議21： 用偶判斷，不用奇判斷
建議22： 用整數(shù)類型處理貨幣
建議23： 不要讓類型默默轉(zhuǎn)換
建議24： 邊界，邊界，還是邊界
建議25： 不要讓四舍五入虧了一方
建議26： 提防包裝類型的null值
建議27： 謹慎包裝類型的大小比較
建議28： 優(yōu)先使用整型池
建議29： 優(yōu)先選擇基本類型
建議30： 不要隨便設置隨機種子
第3章　類、對象及方法
建議31： 在接口中不要存在實現(xiàn)代碼
建議32： 靜態(tài)變量一定要先聲明后賦值
建議33： 不要覆寫靜態(tài)方法
建議34： 構造函數(shù)盡量簡化
建議35： 避免在構造函數(shù)中初始化其他類
建議36： 使用構造代碼塊精煉程序
建議37： 構造代碼塊會想你所想
建議38： 使用靜態(tài)內(nèi)部類提高封裝性
建議39： 使用匿名類的構造函數(shù)
建議40： 匿名類的構造函數(shù)很特殊
建議41： 讓多重繼承成為現(xiàn)實
建議42： 讓工具類不可實例化
建議43： 避免對象的淺拷貝
建議44： 推薦使用序列化實現(xiàn)對象的拷貝
建議45： 覆寫equals方法時不要識別不出自己
建議46： equals應該考慮null值情景
建議47： 在equals中使用getClass進行類型判斷
建議48： 覆寫equals方法必須覆寫hashCode方法
建議49： 推薦覆寫toString方法
建議50： 使用package-info類為包服務
建議51： 不要主動進行垃圾回收
第4章　字符串
建議52： 推薦使用String直接量賦值
建議53： 注意方法中傳遞的參數(shù)要求
建議54： 正確使用String、StringBuffer、StringBuilder
建議55： 注意字符串的位置
建議56： 自由選擇字符串拼接方法
建議57： 推薦在復雜字符串操作中使用正則表達式
建議58： 強烈建議使用UTF編碼
建議59： 對字符串排序持一種寬容的心態(tài)
第5章　數(shù)組和集合
建議60： 性能考慮，數(shù)組是首選
建議61： 若有必要，使用變長數(shù)組
建議62： 警惕數(shù)組的淺拷貝
建議63： 在明確的場景下，為集合指定初始容量
建議64： 多種最值算法，適時選擇
建議65： 避開基本類型數(shù)組轉(zhuǎn)換列表陷阱
建議66： asList方法產(chǎn)生的List對象不可更改
建議67： 不同的列表選擇不同的遍歷方法
建議68： 頻繁插入和刪除時使用LinkedList
建議69： 列表相等只需關心元素數(shù)據(jù)
建議70：子列表只是原列表的一個視圖
建議71： 推薦使用subList處理局部列表
建議72： 生成子列表后不要再操作原列表
建議73： 使用Comparator進行排序
建議74： 不推薦使用binarySearch對列表進行檢索
建議75： 集合中的元素必須做到compareTo和equals同步
建議76： 集合運算時使用更優(yōu)雅的方式
建議77： 使用shuffle打亂列表
建議78： 減少HashMap中元素的數(shù)量
建議79： 集合中的哈希碼不要重復
建議80： 多線程使用Vector或HashTable
建議81： 非穩(wěn)定排序推薦使用List
建議82： 由點及面，一葉知秋-集合大家族
第6章　枚舉和注解
建議83： 推薦使用枚舉定義常量
建議84： 使用構造函數(shù)協(xié)助描述枚舉項
建議85： 小心switch帶來的空值異常
建議86： 在switch的default代碼塊中增加AssertionError錯誤
建議87： 使用valueOf前必須進行校驗
建議88： 用枚舉實現(xiàn)工廠方法模式更簡潔
建議89： 枚舉項的數(shù)量限制在64個以內(nèi)
建議90： 小心注解繼承
建議91： 枚舉和注解結(jié)合使用威力更大
建議92： 注意@Override不同版本的區(qū)別
第7章　泛型和反射
建議93： Java的泛型是類型擦除的
建議94： 不能初始化泛型參數(shù)和數(shù)組
建議95： 強制聲明泛型的實際類型
建議96： 不同的場景使用不同的泛型通配符
建議97： 警惕泛型是不能協(xié)變和逆變的
建議98： 建議采用的順序是List、List、List
建議99： 嚴格限定泛型類型采用多重界限
建議100： 數(shù)組的真實類型必須是泛型類型的子類型
建議101： 注意Class類的特殊性
建議102： 適時選擇getDeclared×××和get×××
建議103： 反射訪問屬性或方法時將Accessible設置為true
建議104： 使用forName動態(tài)加載類文件
建議105： 動態(tài)加載不適合數(shù)組
建議106： 動態(tài)代理可以使代理模式更加靈活
建議107： 使用反射增加裝飾模式的普適性
建議108： 反射讓模板方法模式更強大
建議109： 不需要太多關注反射效率
第8章　異常
建議110： 提倡異常封裝
建議111： 采用異常鏈傳遞異常
建議112： 受檢異常盡可能轉(zhuǎn)化為非受檢異常
建議113： 不要在finally塊中處理返回值
建議114： 不要在構造函數(shù)中拋出異常
建議115： 使用Throwable獲得棧信息
建議116： 異常只為異常服務
建議117： 多使用異常，把性能問題放一邊
第9章　多線程和并發(fā)
建議118： 不推薦覆寫start方法
建議119： 啟動線程前stop方法是不可靠的
建議120： 不使用stop方法停止線程
建議121： 線程優(yōu)先級只使用三個等級
建議122： 使用線程異常處理器提升系統(tǒng)可靠性
建議123： volatile不能保證數(shù)據(jù)同步
建議124： 異步運算考慮使用Callable接口
建議125： 優(yōu)先選擇線程池
建議126： 適時選擇不同的線程池來實現(xiàn)
建議127： Lock與synchronized是不一樣的
建議128： 預防線程死鎖
建議129： 適當設置阻塞隊列長度
建議130： 使用CountDownLatch協(xié)調(diào)子線程
建議131： CyclicBarrier讓多線程齊步走
第10章　性能和效率
建議132： 提升Java性能的基本方法
建議133： 若非必要，不要克隆對象
建議134： 推薦使用“望聞問切”的方式診斷性能
建議135： 必須定義性能衡量標準
建議136： 槍打出頭鳥-解決首要系統(tǒng)性能問題
建議137： 調(diào)整JVM參數(shù)以提升性能
建議138： 性能是個大“咕咚”
第11章　開源世界
建議139： 大膽采用開源工具
建議140： 推薦使用Guava擴展工具包
建議141： Apache擴展包
建議142： 推薦使用Joda日期時間擴展包
建議143： 可以選擇多種Collections擴展
第12章　思想為源
建議144： 提倡良好的代碼風格
建議145： 不要完全依靠單元測試來發(fā)現(xiàn)問題
建議146： 讓注釋正確、清晰、簡潔
建議147： 讓接口的職責保持單一
建議148： 增強類的可替換性
建議149： 依賴抽象而不是實現(xiàn)
建議150： 拋棄7條不良的編碼習慣
建議151： 以技術員自律而不是工人