第 5 章 格式
你應該保持良好的代碼格式。你應該選用一套管理代碼格式的簡單規則，然後貫徹這些規則。如果你在團隊中工作，則團隊應該一致同意採用一套簡單的格式規則，所有成員都要遵從。使用能幫你應用這些格式規則的自動化工具會很有幫助。
5.1 格式的目的
代碼格式很重要。代碼格式不可忽略，必須嚴肅對待。代碼格式關乎溝通，而溝通是專業開發者的頭等大事。
5.2 垂直格式
用大多數爲 200 行、最長 500 行的單個文件構造出色的系統。儘管這並非不可違背的原則，也應該樂於接受。短文件通常比長文件易於理解。
5.2.1 向報紙學習
源代碼也要像報紙那樣。名稱應當簡單且一目瞭然。名稱本身應該足夠告訴我們是否在正確的模塊中。源文件最頂部應該給出高層次概念和算法。細節應該往下漸次展開，直至找到源文件中最底層的函數和細節。
5.2.2 概念間垂直方向上的區隔
幾乎所有的代碼都是從上往下讀，從左往右讀。每行展現一個表達式或一個子句，每組代碼行展示一條完整的思路。這些思路用空白行區隔開來。
在封包聲明、導入聲明和每個函數之間，都有空白行隔開。這條及其簡單的規則極大地影響到代碼的視覺外觀。每個空白行都是一條線索，標識出新的獨立概念。往下讀代碼時，你的目光總會停留於空白行之後那一行。
5.2.3 垂直方向上的靠近
如果說空白行隔開了概念，靠近的代碼行則暗示了它們之間的緊密關係。所以，緊密相關的代碼應該相互靠近。
5.2.4 垂直距離
關係密切的概念應該相互靠近。顯然，這條規則並不適用於分佈在不同文件中的概念。除非有很好的理由，否則就不要把關係密切的概念放到不同的文件中。實際上，這也是避免使用 protected 變量的理由之一。
對於那些關係密切、放置於同一源文件中的概念，他們之間的區隔應該成爲對相互的易懂度有多重要的衡量標準。應避免迫使讀者在源文件和類中跳來跳去。
變量聲明。變量聲明應儘可能靠近其使用位置。因爲函數很短，本地變量應該在函數的頂部出現。
循環中的控制變量應該總是在循環語句中聲明。
偶爾，在較長的函數中，變量也可能在某個代碼塊頂部，或在循環之前聲明。
實體變量應該在類的頂部聲明。這應該不會增加變量的垂直距離，因爲在設計良好的類中，它們如果不是被該類的所有方法也是大多數方法所用。
相關函數。若某個函數調用了另外一個，就應該把它們放在一起，而且調用者應該儘可能放在被調用者上面。這樣，程序就有個自然的順序。若堅定地遵循這條約定，讀者將能夠確信函數聲明總會在其調用後很快出現。
概念相關。概念相關的代碼應該放在一起。相關性越強，彼此之間的距離就該越短。
相關性應建立在直接依賴的基礎上，如函數間調用，或函數使用某個變量。但也有其他相關性的可能。相關性可能來自於執行相似操作的一組函數（相同的函數名稱，執行同一基礎任務的函數）。
5.2.5 垂直順序
一般而言，我們想自上向下展示函數調用依賴的順序。也就是說，被調用的函數應該放在執行調用的函數下面。這樣就建立了一種自頂向下貫穿源代碼模塊的良好信息流。
5.3 橫向格式
應該盡力保持代碼行短小。死守 80 個字符的上限有點僵化，而且也不反對代碼行長度達到 100 個字符或 120 個字符。再多的話，大抵就是肆意妄爲了。
5.3.1 水平方向上的區隔與靠近
我們使用空格字符將彼此緊密相關的事物連接到一起，也用空格字符把相關性較弱的事物分隔開。
在賦值操作符周圍加上空格字符，以此達到強調目的。賦值語句有兩個確定而重要的要素：左邊和右邊。空格字符加強了分隔效果。
另一方面，我不在函數名和左圓括號之間加空格。這是因爲函數與其參數密切相關，如果隔開，就會顯得互無關係。我把函數調用括號中的參數一一隔開，強調逗號，表示參數是互相分離的。
空格字符的另一種用法是強調其前面的運算符。
乘法因子之前沒加空格，因爲它們具有較高優先級。加減法運算項之間用空格隔開，因爲加法和減法優先級較低。
5.3.2 水平對齊
對齊並沒有什麼用，如果有較長的列表需要做對齊處理，那麼問題就是在列表的長度上而不是對齊上。
5.3.3 縮進
源文件是一種繼承結構，而不是一種大綱結構。其中的信息涉及整個文件、文件中每個類、類中的方法、方法中的代碼塊，也涉及代碼塊中的代碼塊。這種繼承結構中的每一層級都圈出一個範圍，名稱可以在其中聲明，而聲明和執行語句也可以在其中解釋。
要讓這種範圍式繼承結構可見，我們依源代碼行在繼承結構中的位置對源代碼行做縮進處理。在文件頂層的語句，例如大多數的類聲明，根本不縮進。類中的方法相對該類縮進一個層級。方法的實現相對方法聲明縮進一個層級。代碼塊的實現相對於其容器代碼塊縮進一個層級，以此類推。
5.3.4 空範圍
有時，while 或 for 語句的語句體爲空，儘量不要使用。如果無法避免，就確保空範圍體的縮進，用括號包圍起來。
5.4 團隊規則
記住，好的軟件系統是由一系列讀起來不錯的代碼文件組成的。它們需要擁有一致和順暢的風格。讀者要能確信，他們在一個源文件中看到的格式風格在其他文件中也是同樣的用法。絕對不要用各種不同的風格來編寫源代碼，這樣會增加其複雜度。
5.5 鮑勃大叔的格式規則
編碼標準文檔的範例。