第45條：將區域性變數的作用域最小化

1. 要使區域性變數的作用域最小化，最有力的方法就是在第一次使用它的地方宣告
2. 幾乎每個區域性變數的宣告都應該保護一個初始化表示式
   1. 例外，try-catch，因為初始化會被拋異常，那麼在try外宣告，在內部初始化
3. 使方法小而集中，使得一個操作相關的變數不會被另一個操作的程式碼操作

第46條：for-each迴圈優先於傳統的for迴圈

1. 迭代器和索引變數更容易出錯

2. for的for(int i = 0; i < a.lenght; i ++) 每次a.length都執行，效能低，容易忘記
3. 例外
   1. 過濾：遍歷刪除部分元素，用remove需要i
   2. 轉換：遍歷列表或者陣列，並取代部分元素值
   3. 平行迭代：同時並行遍歷多個集合
      

第47條：瞭解和使用類庫

類庫雖然比較大，但是還是應該熟悉java.lang, java.util, java.io 包括，collections，concurrent等等

因為類庫受關注和改進比普通人要更受關注，因此使用會更好

第48條：如果需要精確的答案，請避免使用float和double

1. float和double型別主要是為了科學計算和工程計算而設計的，它們執行的是二進位制浮點運算，並沒有提供完全精確的結果，如（1 - 9 * .10） = 0.09999999999999998
2. 用BigDecimal，int或者long進行精確計算，尤其是貨幣的時候
3. BigDecimal，優點，完全控制舍入模式8種，缺點，不方便（型別），慢。
4. 如果數值範圍沒有超過9位十進位制數字，就可以使用int；如果不超過18位數字，就可以使用long；如果數值可能超過18位數字，就必須使用BigDecimal。

第49條：基本型別優先於裝箱基本型別

1. 選擇的時候優先使用基本型別
2. 這些時候應該使用裝箱基本型別
   1. 作為集合中的元素，鍵和值
   2. 引數化型別<T>中
   3. 進行反射的方法呼叫
3. 當一項操作中混合基本型別和裝箱基本型別時，裝箱基本型別就會自動拆箱，可能會導致NullPointException；另，自動裝箱減少了使用裝箱基本型別的繁瑣，但並沒有減少風險。當程式用==比較兩個裝箱基本型別時候，做了同一性比較，幾乎肯定不是你所希望的
4. 裝箱導致高開銷和不必要的物件建立

第50條：如果其他型別更合適，則儘量避免使用字串

1. 字串不適合代替其他的值型別，如int，是否的boolean等
2. 不適合代替列舉
3. 不適合代替聚集型別，如使用分隔符來儲存資料，不是好的方式 ，a#b#c，以#來間隔
4. 不適合代替能力表，如用string基於鍵的api

第51條：當心字串連線的效能

1. +是把多個字串合併為一個字串的遍歷途徑，但是大規模時候，為連線n個字串，重複使用連線符操作，需要n的平方級。因為字串是不可變的，造成了很多需要垃圾回收的中間物件。事實上，每個+會自動引入一個StringBuilder，來構造新的string。
2. 使用StringBuilder的append方法，分配一次，使用多次，可以預分配大小，也可以讓其自動擴充套件
3. 原則，不要使用字串連線符來合併多個字串，除非效能無關緊要。應該使用StringBuilder或者String陣列

第52條：通過介面引用物件

1. 如果有合適的介面型別存在，那麼對於引數，返回值，變數和域來說，就都應該使用介面型別進行宣告，通常更改實習的時候，只是更改構造器中類的名稱，如
   

   List<Subscriber> subscribers = new Vector<Subscriber>();
   改為
   List<Subscriber> subscribers = new ArrayList<Subscriber>();

2. 注意：如果原來的實現提供了特殊的功能，而這種功能並不是介面所有，周圍的程式碼又依賴於次功能，新的實現也要提供同樣的功能。
3. 如果沒有合適的介面存在完全可以用類而不是介面來引用物件，如值型別，已經沒有關聯介面的具體類
4. 物件屬於框架，則用基礎類來引用物件 如java.util.TimerTask
   
5. 類實現介面，但是有介面沒有的方法
6. 總之，介面引用物件會使程式更加靈活，如果不能，使用類層次結構中提供了畢業功能的最基礎的類

第53條：介面優先於反射機制

對反射理解不深

第54條：謹慎地使用本地方法

1. 指使用本地程式設計語言編寫的特殊方法
2. jvm越來越快，本地方法提供效能不值得
3. 本地語言不安全，平臺相關，不方便移植
4. 儘可能少使用，必要時候才使用，而且極少數情況會用到，並全面測試

第55條：謹慎第進行優化

不要費力去編寫快速的程式，應該努力編寫好的程式，速度隨之而來

第56條：遵守普遍接受的命名慣例

如果長期養成的習慣與此不同，不要盲目遵從這些命名規範，可以運用常識