第五章 格式
1、格式的目的
代碼格式關乎溝通，而溝通是開發者的大事。
2、垂直格式
- 向報紙學習--由多篇文章組成，多數短小而精悍，有些稍微長一點
- 概念間垂直方向上的間隔--在封包聲明、導入聲明和每個函數之間，都有空白行隔開
- 垂直方向上的靠近--緊密相關的代碼應該相互靠近
- 垂直距離--關係密切的概念應該互相靠近，除非有很好的理由，否則不要把關係密切的概念放到不同的文件中。變量聲明應儘可能的靠近其使用位置；某個函數調用了另一個，就應該把他們放在一起，而且調用者應該儘可能的在被調用者上面；對於具有相似功能的函數，也應將他們放在一起，互相調用是第二位的
- 垂直順序--自上而下展示函數順序，被調用者放在調用者的下面
3、橫向格式
- 一行的代碼數不要超過120字符
- 使用空格字符將彼此相關的事物連接到一起，也用空格符將相關性較弱的事物隔開。 比如在賦值符合的兩邊加空格加以強調，在參數的後面加空格表示參數沒有關聯
- 水平對齊--不需要水平對齊
- 縮進--大多數的類聲明，根本不縮進。類中的方法相對該類縮進一個層級。方法的實現相對方法的聲明縮進一個層級。代碼塊的實現相對於其容器代碼塊縮進一個層級。
4、團隊規則
一組開發者應當認同一種格式風格，每個成員都應該採用那種風格。
第六章 對象和數據結構
1、數據抽象
隱藏實現 不暴露數據細節，以抽象形態表述數據。不只是用接口和/或賦值器
2、數據、對象的反對稱性
過程式代碼（使用數據結構的代碼）便於在不改動既有數據結構的前提下添加新函數，面向對象代碼便於在不改動既有函數的情況下添加新類。
對於面向對象比較難的事情，對於面向過程卻比較容易，反之亦然。
3、得墨忒耳率
得墨忒耳率認爲，模塊不應瞭解它所操作對象的內部情形。
方法不應該調用由任何函數返回的對象的方法。
對於一連串的函數調用，我們可以將要完成的任務直接封裝到方法中，從而隱藏內部數據並且防止函數因瀏覽他不該知道的對象而違法得墨忒耳率。
4、數據傳送對象
最爲精煉的數據對象，是一個只有公共變量，沒有函數的類。這種數據結構有時被稱爲數據傳送對象或DTO（Data Transfer Objects）。DTO是非常有用的結構，尤其是在於數據庫通信、或解析套接字傳遞的消息之類的場景中。
第七章 錯誤處理
1、錯誤處理很重要，但是如果他搞亂了代碼邏輯，就是錯誤的做法。
2、使用異常而非錯誤碼
3、先寫Try-Catch-Finally語句
在某種意義上，try代碼塊就像是事物。catch代碼塊將程序維持在一種持續狀態，無論try代碼塊發生了什麼均如此。
4、使用不可控異常
可控異常（每個方法的簽名都列出他可能傳遞給調用者的異常）的代價就是違反開放/閉合原則。如果我們修改一個較低層級的方法，都需要修改涉及的高級別的簽名。
5、給出異常發生的環境說明
拋出的每個異常，都應當提供足夠的環境說明，以便判斷錯誤的來源和處所。應創建信息充分的錯誤消息，並和異常一起傳遞出去
6、依調用者需要定義異常類
當對一個事件需要做多種錯誤處理時，我們可以通過打包調用API，確保它返回通用異常類型，從而簡化代碼。
如：
上圖將ACMEPort進行封裝，並且爲類定義了一個異常類型
7、定義常規流程
特例模式（SPECIAL CASE PATTERN）創建一個類或配置一個對象，用來處理特例。
8、別返回null值
如果返回了null值，會需要多判斷是否爲null,或者需要catch NullPointException，不如更改代碼直接不返回null。
9、別傳遞null值
除非API要求你向它傳遞null值，否則就要儘可能避免傳遞null值
10、小結--整潔代碼是可讀的，但也要強固。可讀與強固並不衝突。