第五章 格式

縱向格式： 1. 函式與函式之間留空行。 2.變數宣告：變數宣告應該儘可能靠近其使用位置。因為函式很短，本地變數應該在函式的頂部出現。 3.實體變數 應該在內的頂部，相當於我們的field 欄位，會被使用的多。 4.相關函式，如果某個函式呼叫另外一個，就應該把他們放在一起，而且呼叫者應該儘可能放在被呼叫者的上面。這樣這個程式就會自然有序。（之前我喜歡把private的方法 放到一起。當然這確實沒有什麼實際的意義） 5.“相關概念的程式碼放在一起。相關性越強，比如一個大功能邏輯靠在一起。” （更多的時候我喜歡用 region 來收起來。） 橫向格式：

1.一行的長度，作者建議是上限是120個字元

PS 平時我們都是按照自己的螢幕大小來決定，當然太長了，自己也不便閱讀，又不是壓縮的js檔案

2.賦值語句兩端留空。

a = b ; 

3.不在函式名和左括號間加空格。因為函式與其引數密切相關。 4.縮排。原始檔是一種繼承結構，而不是一種大綱結構，繼承結構中的每一層級都圈出一個範圍， 也就是程式碼塊，其中有宣告語句和執行語句。要體現這種繼承結構，就要對原始碼進行縮排處理。但有時候我們會把if語句，while迴圈，或小函式寫成一行，但這樣沒有層級的概念，不便閱讀，還是縮排的好。

第六章 物件和資料結構

1.過程式程式碼（函式程式設計）便於在不改動既有資料結構的前提下新增新函式，面向物件程式碼便於在不改動既有函式的前提下新增新類。反過來講也說的通,過程式程式碼難以新增新的資料結構，因為必須修改所有函式，面向物件程式碼難以新增新函式，因為必須修改所有類。所以在設計的時候要分析好是以後是要新增新函式還是要新增新的資料結構。

2.德墨忒爾律：模組不應該瞭解它所操作物件內部情形。比如C的方法f只能呼叫以下物件的方法。

• C
• 由f建立的物件
• 作為引數傳遞給f的物件
• C的實體變數持有的變數

var outpath=cxt.getOptions().getScart().getAbsolutePath();

這個程式碼就違反了上面的德墨忒爾律，呼叫了返回值的方法。這樣就是暴露了內部結構。

第七章 異常處理

1.try程式碼就像是事務，catch程式碼塊將程式維持在一種持續狀態。在編寫可能丟擲異常的程式碼時，最好先寫出try-catch-finally 語句。

2.根據需要定義異常類。對錯誤分類的方式有多種，可以依據來源，是元件還是其他地方，或者依據型別，是裝置錯誤還是網路錯誤。不過在我們定義異常類的時候，最重要的考慮是如何捕獲它們。

3.別返回null值。程式中不斷的看到檢測null值的程式碼，一處漏掉檢測就可能會失控。返回Null，作者認為這種程式碼很糟糕。建議丟擲異常 或者返回特定物件（預設值）。更早的發現問題。同理，也應該避免傳遞Null值給其他的方法。

PS:在大多數的程式語言中，沒有良好的方法能對付由呼叫者意外傳入的null值。我們釋出產品應該有容錯的機制，程式不能輕易的就崩掉，有異常應該及時記錄下來或給出提示。

連結：https://www.jianshu.com/p/b8f0846e0ea2

以前自己的做法：有時候打程式碼是不注重縮排的感覺沒有影響 不過確實不美觀

現在的做法：控制好程式碼的縮排加異常處理