## 第三章 註解
1. 如果遇到很糟糕的程式碼，不要去註解他，而是去重構他。通常註解會隨著時間跟需求的變動，導致原本他要解釋的地方不見或是搬移，而常常搬移會忘記把註解一起移動過去目標位置。所以書中才建議是去重構而不是用註解的方式描述他
2. 通常命名取的好，以及函式有做好該做的事情，很少會需要註解。這也代表用程式碼去表達往往比用註解來的好
3. 註解有分成有益的註解跟糟糕的註解
1. 有益的註解
1-1. 法律型 -> 有些公司會強迫寫下關於法律方面的註解，像是著作權聲明及作者資訊。但他不應該是契約或法律條款，通常這種的會建議直接改成連結，讓想看的人再連過去看就好。
1-2. 資訊型 -> 通常建議還是能夠透過命名讓人一目了然會比較好，但像是日期的話也是可以這樣做資料格式可以這麼做沒關係，因為日期通常是 %d %d %d(年月日或是日月年)，如果沒有抽成function來做的話這時就可以註解寫一下順序是甚麼
1-3. 對於後果的描述 -> 舉例來說有時會把特定測試註解掉，因為跑完的時間會花費很久，如果沒有特別描述就會先踩過坑才知道痛點在哪裡
1-4. 代辦事項 -> 描述說某些地方未來會改進或是調整時就可以使用，但也要定期去看說有那些TODO沒有處理完，否則整個專案裡會充斥todo的註解
2. 糟糕的註解
2-1. 喃喃自語 - 只覺得這裡應該要寫註解，然後就寫了。通常要寫註解，應該要花上必要的時間來確保他是最好的註解。如果還要去特別看程式本身如何運作的話就會是糟糕的註解
2-2. 多餘、誤導的註解 - 通常就代表了直接看程式本身會比去看註解本身來的更好，因為人通常有註解會先看註解，而若是看了沒有甚麼幫助，更糟糕的是有可能誤導其他開發者
2-3. 干擾型註解 - 就是把很基本、明顯的事實描述一遍，像下面的例子就是這類型

        // The day of the month
        private int dayOfMonth

2-4 註解起來的程式碼 - 如果沒有使用到就把他刪掉吧，否則後續接手的人如果不清楚也部會敢貿然刪除

## 第四章 編排
這章節的開頭有講到好的編排會讓眉毛不由自主地上揚，一團雜亂的程式碼會看起來像一群喝醉的水手撰寫的，有可能會斷定不細心的行為很有可能出來害到正在開發的我們
1. 編排的目的是讓我們開發者看得舒服，再來有了完整的第一次，之後的每一次開發才會錦然有序，否則很容易因為一次的錯誤，導致後面程式的編寫風格就混亂起來，可讀性也會影響可維護性及可擴充性。就算程式碼內容已經被改成跟你寫得不一樣，但風格的部分依舊會存在。
2. 通常一個檔案裏面的行數在一個大型系統，以一些開源的專案來說，200~500行的程式碼是可以辦得到，如果超過500行就可以想辦法抽出其中的一些東西，來讓之後觀看的人減輕心理上壓力
3. 在一個檔案中，會使用再一起的程式跟變數會盡量放在一起，而不同邏輯之間則用空白區隔，這樣一來觀看時可以很清楚知道這一區塊是相關的
4. 在水平編排中，作者是建議不需使用卷軸捲到右方才是適當的寬度，以及作者建議的上限是120字元。會這樣說是因為現在編輯器可以很個人化設定，有些人字體大小偏大，很容易造成螢幕出現卷軸，反之則可以放很多。所以要怎麼做，還是依照團隊規定來走會比較好。
5. 既然有垂直的空白(程式碼之間的間隔)，就一定會有水平的空白，水平的空白指的是設定運算子(也就是 = )，在他的前後都放一個空白，這樣看起來會更突出。而函式跟他的參數之間的括號作者則不會空白，空白會讓兩者看起來不相關，而參數跟參數之間則會逗號後空白，這樣就可以分開。還有一種則是強調運算子的優先順序，而這個就有點見仁見智，因為大部分的linter對於這種的優先順序比較沒有支援。所以要自己做的話通常會比較麻煩一些，而且有可能你排好後再讓自動化工具排，有可能你剛剛做的就會消失(等於做白工)。

// 設定運算子之間的空格
let i = 1
// 參數之間的空白以及參數與函式的空白
function hello(name, time){
    console.log("Hello, " + name +" time is " + time)
}
hello("leave3310", "2023/8/1")

6. 水平的對齊很容易強調不該注意的東西，導致無法看到程式真正的意圖，很容易忽略型態、忽略設定運算子。而且最重要的是，你剛排好後用自動化工具排會毀掉你剛剛所做的一切!

pulbic class Test{
    private Socket      socket;
    private InputStream input;
    private long        requestProgress;
}

7. 縮排在某些情況下有可能違反規則，像是簡短的if、while、function等等都有可能造成你只想一行解決，但作者還是有回去調整這些程式的縮排。風格有統一的話在觀看時才不用一直切換自己在觀看時的視野

public class Test2{
    public void returnHello(){return "hello";}
}
public class Test2{
    public void returnHello(){
        return "hello";
    }
}

8. 每個人都一定有自己喜歡的排版準則，但是如果你在一個團隊中，**必須以團隊的編排準則為主**，否則每個檔案裡的編排風格不一樣害到的永遠是那個團隊裡的所有人(除非你離職)，如果參雜個人風格的程式碼，很容易增加閱讀原始碼的複雜性