1、代碼格式不可忽略，必須嚴肅對待。代碼格式關乎溝通，而溝通是專業(yè)開發(fā)者的頭等大事。
2、在java中，文件尺寸與類尺寸極其相關。
3、源文件名稱本身應該足夠告訴我們是否在正確的模塊中。源文件最頂部應該給出高層概念和算法。細節(jié)應該往下漸次展開，直至找到源文件中最底層的函數和細節(jié)。
4、幾乎所有的代碼都是從上往下讀，從左往右讀。每行展現(xiàn)一個表達式或一個子句，每組代碼行展示一條完整的思路。這些思路用空白行區(qū)隔開來。
5、如果說空白行隔開了概念，靠近的代碼行則暗示了它們之間的緊密關系。所以，緊密相關的代碼應該互相靠近。
6、關系密切的概念應該相互靠近。顯然，這條規(guī)則并不適用于分布在不同文件中的概念。除非有很好的理由，否則就不要把關系密切的概念放在不同的文件中。實際上，這也是避免使用protected變量的理由之一。
7、對于那些關系密切、放置同一源文件的概念，它們之間的區(qū)隔應該成為對相互的易懂度有多重要的衡量標準。應避免迫使讀者在源文件和類中跳來跳去。
8、變量聲明應盡可能靠近其使用位置。因為函數很短，本地變量應該在函數的頂部出現(xiàn)。循環(huán)中的控制變量應該總是在循環(huán)語句中聲明。偶爾，在較長的函數中，變量也可能在某個代碼塊頂部，或在循環(huán)之前聲明。
9、實體變量應該在類的頂部聲明。這應該不會增加變量的垂直距離，因為在設計良好的類中，它們如果不是被類的所有方法也是在被大多數方法所用。
10、若某個函數調用了另外一個，就應該把它們放到一起，而且調用者應該盡可能放在被調用者上面。這樣，程序就有個自然的順序。若堅定地遵循這條約定，讀者將能夠確信函數聲明總會在其調用后很快出現(xiàn)。
11、概念相關的代碼應該放到一起。相關性越強，彼此之間的角力就該越短。相關性應建立在直接依賴的基礎上，如函數間調用，或函數使用某個變量。但也有其他相關性的可能。相關性可能來自于執(zhí)行相似操作的一組函數。 12、一般而言，我們想自上而下展示調用依賴順序。也就是說，被調用的函數應該放在執(zhí)行調用的函數下面。這樣就建立了一種自頂向下貫穿源代碼模塊的良好信息流。
13、一行代碼應該有多寬？程序員更喜愛短行代碼。所以，應盡力保持代碼行短小。死守80個字符的上限有點僵化，而且我也并不反對代碼行長度達到100個字符或120個字符。再多的話，大抵就肆意妄為了。
14、我們使用空格字符將彼此緊密相關的事物連接到一起，也用空隔把關系性弱的事物分隔開。賦值語句有兩個確定而重要的要素：左邊和右邊?？崭褡址訌娏朔指粜ЧＡ硪环矫?，不在函數名和左圓括號之間加空格。這是因為函數與其參與密切相關，如果分隔開，就會顯得互無關系。把函數調用括號中的參數一 一 隔開，強調逗號，表示參數是互相分離的。
15、乘法因子之間不加空格，因為它們具有較高優(yōu)先級。加減法運算項之間用空格隔開，因為加法和減法優(yōu)先級較低。但是多數代碼格式化工具都會漠視運算符優(yōu)先級，從頭到尾采用同樣的空格方式。
16、水平對齊，像是在強調不重要的東西，把程序員的目光從真正意義上拉開。建議用不對齊的聲明和賦值。如果有較長的列表需要做對齊處理，那問題就是在列表的長度上而不是對齊上。
17、源文件是一種繼承結構，而不是一種大綱結構。其中的信息涉及整個文件、文件中每個類、類中的方法、方法中的代碼塊，也涉及代碼塊中的代碼塊。這種繼承結構中的每一層級都圈出一個范圍，名稱可以在其中聲明，而聲明和執(zhí)行語句也可以在其中解釋。要讓這種范圍式繼承結構可見，我們依源代碼在繼承結構中的位置對源代碼行做縮進處理。在文件頂層的語句，例如大多數的類聲明，根本不縮進。類中的方法相對該縮進進一個層級。方法的實現(xiàn)相對聲明縮進一個層級。代碼塊的實現(xiàn)相對于其容器代碼縮進塊縮進一個層級，以此類推。
18、程序員相對依賴這種縮進模式。他們從代碼左邊查看自己在什么范圍中工作。這讓他們能快速跳過與當前關注的情形無關的范圍，例如if或while語句的實現(xiàn)之類。他們的眼光掃過左邊，查找新的方法聲明、新變量，甚至新類。沒有縮進的話，程序就會變得無法閱讀。
19、有時，while或for語句的語句體為空，如果無法避免，就確?？辗秶w的縮進，用括號包圍起來。
20、每個程序員都有自己喜歡的格式規(guī)則，但如果在一個團隊中工作，就是團隊說了算。一組開發(fā)者應當認同一種格式風格，每個成員都應該采用那種風格。
下載文檔
