你應該選擇一套管理代碼格式的簡單規則。如果是團隊，應該選擇一套團隊一致同意采用的簡單格式規則。
最重要的原則：一致性（Consistency）！
- 沒有完美的格式規范，但有統一的規范。 整個團隊（或者你自己寫項目時）要定下一套格式規則，然后所有人都要嚴格遵守它。哪怕某個規則你不太喜歡，為了團隊整體的代碼風格統一，也得遵循。
- 為什么？ 讀代碼時，大腦就不用去適應不同的排版風格了，可以把精力完全放在理解代碼邏輯上。
- 強烈建議： 使用自動化代碼格式化工具（IDE 里通常都有，比如 IntelliJ IDEA 的 Reformat Code，Eclipse 的 Format），并配置好團隊統一的格式規范，讓工具去強制執行排版規則。
格式的目的
代碼格式關乎溝通，而溝通是專業開發者的頭等大事。
你今天編寫的功能，即有可能在下一版被修改，而代碼的可讀性會對以后可能發生修改行為產生深遠影響。
垂直格式（Vertical Formatting）- 像寫文章一樣組織代碼
想象你的代碼文件是一張紙，你怎么在紙上從上往下安排內容？
- 報紙頭條原則： 文件頂部應該包含最高層次、最概括的概念（比如類名、最重要的功能）。越往下，代碼應該越詳細，越具體。就像讀報紙，先看大標題、導語，再看詳細報道。
- 概念之間要留白： 用空行把不相關的概念隔開，就像文章段落之間要有空行一樣。
-
- 比如兩個方法之間，應該用空行隔開。
- 一個方法內部，不同邏輯塊之間（比如初始化變量、執行主要計算、處理結果這三個步驟）也應該用空行稍微隔開，增強可讀性。
- 相關性要緊密： 關系非常緊密的代碼（比如屬于同一個邏輯步驟的連續幾行代碼）應該緊挨著，不要用空行隔開，表示它們是一個整體。
- 相關代碼要靠近： 概念上相關的代碼，比如調用者和被調用者、使用某個變量的代碼和定義這個變量的代碼，在垂直距離上應該盡量靠近。理想情況下，調用者應該在被調用者上面（回想第三章的向下原則）。很顯然這條規則不使用于分布在不同文件的概念。除非有很好的理由，否則不要把關系密切的概念放到不同文件中，這也是避免使用 protected 的原因。
- 垂直距離：概念相關，概念相關的代碼應該放到一起，相關性越強，彼此的距離越短。變量聲明，本地變量聲明盡可能靠近使用位置，實體變量應該聲明在類的頂部位置，這會在大多數方法用到。函數相關，若一個函數調用了另一個函數，應該緊密的把這兩個函數垂直放到一起，調用者放到函數上面，這樣極大的增加了可讀性，程序就有一個自然順序。
- 文件總長度： 文件不應該無限長。如果一個文件太長（比如超過幾百行），可能意味著這個類或模塊承擔了太多的責任，可以考慮拆分成多個文件/類。太長的文件翻起來也很費勁。
垂直順序
一般而言，我們想自上向下展示函數調用依賴順序。也就是說，被調用的函數應該放在執行調用的函數下面 1。這樣就建立了一種自頂向下貫穿源代碼模塊的良好信息流。
像報紙文章一般，我們指望最重要的概念先出來，指望以包括最少細節的方式表述它們。我們指望底層細節最后出來。這樣，我們就能掃過源代碼文件，自最前面的幾個函數獲知要旨，而不至于沉溺到細節中。
橫向格式
想象怎么把一行行的代碼寫得更舒服？
空格的使用：
- 在操作符兩邊加空格： 讓代碼看起來不擁擠，更容易分辨不同的元素。例如
a = b + c;而不是a=b+c;。 - 逗號后面加空格： 比如
method(arg1, arg2); - 方法名和括號之間不要有空格：
methodName();而不是methodName ();。 - 關鍵字后面加空格：
if (...),for (...),while (...)。
縮進（Indentation）：這是水平格式中最重要的！ 縮進表示了代碼的層級結構。每一個代碼塊（比如 if 體、for 循環體、方法體、類體）都應該相對于其外層塊進行縮進。嚴格且一致的縮進是代碼可讀性的基石。
不要對齊變量聲明或賦值： 有些人喜歡讓多行變量聲明的賦值符號 = 對齊。雖然看起來整齊，但當你修改其中一行時，可能導致很多其他行的等號位置也需要調整，這在代碼版本管理（Git Diff）時會產生很多不相關的修改，干擾 Code Review。
空范圍
如果循環語句塊為空，不要在結尾加分號，容易看不見，你可以就用空括號，確保縮進，或者換行加 ；，這樣也有點丑
)
——DateTimePicker?控件解析)
)
