- 前言
- 第1章 Java開發中通用的方法和準則
- 建議2:莫讓常量蛻變成變量
- 建議3:三元操作符的類型務必一致
- 建議4:避免帶有變長參數的方法重載
- 建議5:別讓null值和空值威脅到變長方法
- 建議6:覆寫變長方法也循規蹈矩
- 建議7:警惕自增的陷阱
- 建議8:不要讓舊語法困擾你
- 建議9:少用靜態導入
- 建議10:不要在本類中覆蓋靜態導入的變量和方法
- 建議11:養成良好習慣,顯式聲明UID
- 建議12:避免用序列化類在構造函數中為不變量賦值
- 建議13:避免為final變量複雜賦值
- 建議14:使用序列化類的私有方法巧妙解決部分屬性持久化問題
- 建議15:break萬萬不可忘
- 建議16:易變業務使用腳本語言編寫
- 建議17:慎用動態編譯
- 建議18:避免instanceof非預期結果
- 建議19:斷言絕對不是雞肋
- 建議20:不要只替換一個類
- 第2章 基本類型
- 建議22:用整數類型處理貨幣
- 建議23:不要讓類型默默轉換
- 建議24:邊界,邊界,還是邊界
- 建議25:不要讓四捨五入虧了一方
- 建議26:提防包裝類型的null值
- 建議27:謹慎包裝類型的大小比較
- 建議28:優先使用整型池
- 建議29:優先選擇基本類型
- 建議30:不要隨便設置隨機種子
- 第3章 類、對象及方法
- 建議32:靜態變量一定要先聲明後賦值
- 建議33:不要覆寫靜態方法
- 建議34:構造函數盡量簡化
- 建議35:避免在構造函數中初始化其他類
- 建議36:使用構造代碼塊精煉程序
- 建議37:構造代碼塊會想你所想
- 建議38:使用靜態內部類提高封裝性
- 建議39:使用匿名類的構造函數
- 建議40:匿名類的構造函數很特殊
- 建議41:讓多重繼承成為現實
- 建議42:讓工具類不可實例化
- 建議43:避免對象的淺拷貝
- 建議44:推薦使用序列化實現對象的拷貝
- 建議45:覆寫equals方法時不要識別不出自己
- 建議46:equals應該考慮null值情景
- 建議47:在equals中使用getClass進行類型判斷
- 建議48:覆寫equals方法必須覆寫hashCode方法
- 建議49:推薦覆寫toString方法
- 建議50:使用package-info類為包服務
- 建議51:不要主動進行垃圾回收
- 第4章 字符串
- 建議53:注意方法中傳遞的參數要求
- 建議54:正確使用String、StringBuffer、StringBuilder
- 建議55:注意字符串的位置
- 建議56:自由選擇字符串拼接方法
- 建議57:推薦在複雜字符串操作中使用正則表達式
- 建議58:強烈建議使用UTF編碼
- 建議59:對字符串排序持一種寬容的心態
- 第5章 數組和集合
- 建議61:若有必要,使用變長數組
- 建議62:警惕數組的淺拷貝
- 建議63:在明確的場景下,為集合指定初始容量
- 建議64:多種最值算法,適時選擇
- 建議65:避開基本類型數組轉換列表陷阱
- 建議66:asList方法產生的List對像不可更改
- 建議67:不同的列表選擇不同的遍歷方法
- 建議68:頻繁插入和刪除時使用LinkedList
- 建議69:列表相等只需關心元素數據
- 建議70:子列表只是原列表的一個視圖
- 建議71:推薦使用subList處理局部列表
- 建議72:生成子列表後不要再操作原列表
- 建議73:使用Comparator進行排序
- 建議74:不推薦使用binarySearch對列表進行檢索
- 建議75:集合中的元素必須做到compareTo和equals同步
- 建議76:集合運算時使用更優雅的方式
- 建議77:使用shuffle打亂列表
- 建議78:減少HashMap中元素的數量
- 建議79:集合中的哈希碼不要重複
- 建議80:多線程使用Vector或HashTable
- 建議81:非穩定排序推薦使用List
- 建議82:由點及面,一葉知秋集合大家族
- 第6章 枚舉和註解
- 建議84:使用構造函數協助描述枚舉項
- 建議85:小心switch帶來的空值異常
- 建議86:在switch的default代碼塊中增加AssertionError錯誤
- 建議87:使用valueOf前必須進行校驗
- 建議88:用枚舉實現工廠方法模式更簡潔
- 建議89:枚舉項的數量限制在64個以內
- 建議90:小心註解繼承
- 建議91:枚舉和註解結合使用威力更大
- 建議92:注意@Override不同版本的區別
- 第7章 泛型和反射
- 建議94:不能初始化泛型參數和數組
- 建議95:強制聲明泛型的實際類型
- 建議96:不同的場景使用不同的泛型通配符
- 建議97:警惕泛型是不能協變和逆變的
- 建議98:建議採用的順序是List<T>、List<?>、List<Object>
- 建議99:嚴格限定泛型類型採用多重界限
- 建議100:數組的真實類型必須是泛型類型的子類型
- 建議101:注意Class類的特殊性
- 建議102:適時選擇getDeclared×××和get×××
- 建議103:反射訪問屬性或方法時將Accessible設置為true
- 建議104:使用forName動態加載類文件
- 建議105:動態加載不適合數組
- 建議106:動態代理可以使代理模式更加靈活
- 建議107:使用反射增加裝飾模式的普適性
- 建議108:反射讓模板方法模式更強大
- 建議109:不需要太多關注反射效率
- 第8章 異常
- 建議111:採用異常鏈傳遞異常
- 建議112:受檢異常盡可能轉化為非受檢異常
- 建議113:不要在finally塊中處理返回值
- 建議114:不要在構造函數中拋出異常
- 建議115:使用Throwable獲得棧信息
- 建議116:異常只為異常服務
- 建議117:多使用異常,把性能問題放一邊
- 第9章 多線程和並發
- 建議119:啟動線程前stop方法是不可靠的
- 建議120:不使用stop方法停止線程
- 建議121:線程優先級只使用三個等級
- 建議122:使用線程異常處理器提升系統可靠性
- 建議123:volatile不能保證數據同步
- 建議124:異步運算考慮使用Callable接口
- 建議125:優先選擇線程池
- 建議126:適時選擇不同的線程池來實現
- 建議127:Lock與synchronized是不一樣的
- 建議128:預防線程死鎖
- 建議129:適當設置阻塞隊列長度
- 建議130:使用CountDownLatch協調子線程
- 建議131:CyclicBarrier讓多線程齊步走
- 第10章 性能和效率
- 建議133:若非必要,不要克隆對像
- 建議134:推薦使用「望聞問切」的方式診斷性能
- 建議135:必須定義性能衡量標準
- 建議136:槍打出頭鳥解決首要系統性能問題
- 建議137:調整JVM參數以提升性能
- 建議138:性能是個大「咕咚」
- 第11章 開源世界
- 建議140:推薦使用Guava擴展工具包
- 建議141:Apache擴展包
- 建議142:推薦使用Joda日期時間擴展包
- 建議143:可以選擇多種Collections擴展
- 第12章 思想為源
- 建議145:不要完全依靠單元測試來發現問題
- 建議146:讓註釋正確、清晰、簡潔
- 建議147:讓接口的職責保持單一
- 建議148:增強類的可替換性
- 建議149:依賴抽像而不是實現
- 建議150:拋棄7條不良的編碼習慣
- 建議151:以技術員自律而不是工人
讀古今文學網 > 編寫高質量代碼:改善Java程序的151個建議小說線上看 >
編寫高質量代碼:改善Java程序的151個建議
內容簡介:在通往Java技術殿堂的路上,本書將為你指點迷津!內容全部由Java編碼的最佳實踐組成,從語法、程序設計和架構、工具和框架、編碼風格和編程思想等五大方面對Java程序員遇到的各種棘手的疑難問題給出了經驗性的解決方案,為Java程序員如何編寫高質量的Java代碼提出了151條極為寶貴的建議。對於每一個問題,不僅以建議的方式從正反兩面給出了被實踐證明為十分優秀的解決方案和非常糟糕的解決方案,而且還分析了問題產生的根源,猶如醍醐灌頂,讓人豁然開朗。全書一共12章,1~3章針對Java語法本身提出了51條建議,例如覆寫變長方法時應該注意哪些事項、final修飾的常量不要在運行期修改、匿名類的構造函數特殊在什麼地方等;4~9章重點針對JDKAPI的使用提出了80條建議,例如字符串的拼接方法該如何選擇、枚舉使用時有哪些注意事項、出現NullPointerException該如何處理、泛型的多重界限該如何使用、多線程編程如何預防死鎖,等等;10~12章針對程序性能、開源的工具和框架、編碼風格和編程思想等方面提出了20條建議。本書針對每個問題所設計應用場景都非常典型,給出的建議也都與實踐緊密結合。書中的每一條建議都可能在你的下一行代碼、下一個應用或下一個項目中嶄露頭角,建議你將此書擱置在手邊,隨時查閱,一定能使你的學習和開發工作事半功倍。……