團隊應該一致同意採用一套簡單的格式規則，可以運用將這些規則自動化的工具。
代碼格式關乎溝通，而溝通是專業開發人員的頭等大事。
或許你認為“讓代碼能工作”才是專業開發人員的第一優先順序。你今天編寫的功能，極有可能在下一版本中被修改，但代碼的可讀性卻會對以後可能發生的修改行為產生深遠影響。原始代碼修改之後很久，其代碼風格和可讀性仍會影響到可維護性和擴充性。即便代碼已不複存在，你的風格和律條仍存活下來。
向報紙學習看看寫得很好的報紙。從上到下閱讀，在頂部，有頭條，告訴你故事主題。然後第一段是大綱，接著細節漸次增加。原始碼應當一樣，名稱簡單且一目瞭然。源檔案最頂部應該給出高層次概念和演算法。細節應該往下漸次展開，直到最底層的函數和細節。報紙有許多篇文章，多數短小精悍。假若一份報紙只登一篇長篇故事，沒人會去讀它。
概念間垂直方向上的區隔每 一組程式碼展示一條完整的思路，這些思路需要用空白行區隔開來。（國畫中的留白！）每一行都可以標識出新的獨立概念,下面就是一個好個樣本:package fitnesse.wikitext.widgets;
import java.util.regex.*;
public class BoldWidget extends ParentWidget{ public static final String REGEXP = “’’’.+?’’’”; private static final Pattern pattern = Pattern.compile(“’’’’(.+?)’’’”, Pattern.MULTILINE + Pattern.DOTALL);
Public BoldWidget(…) throws Exception { … }}
垂直方向上的靠近正因為空白行隔開了概念，靠近的程式碼則暗示了它們之間的緊密關係。這有助於對代碼的理解。
垂直距離關係密切的概念應該互相靠近。應避免迫使讀者在源檔案和類中跳來跳去。
變數聲明儘可能靠近其使用位置。相關的函數也應遵循從上及下的思路來排列。
垂直順序被調用的函數應該放在執行調用的函數下面，建立一種自頂向下貫穿的良好資訊流。像讀文章一樣，最重要的概念先出來，最底層的細節最後出來。自最前面的幾個函數獲知要旨，而不至於迷失於細節中。
水平方向的區隔與靠近空白字元可以把相關性較弱的事物分隔開。如:int lineSize = line.length();lineWidthHistogram.addLine(lineSize, lineCount);
縮排程式員相當依賴縮排模式來看清楚自己在什麼範圍工作，這樣可以快速跳過與當前關注的情形無關的範圍。
團隊規則在團隊中，規則由團隊說了算。好的軟體系統是由一系列讀起來不錯的代碼檔案組成的，它們需要一致和順暢的風格。不同的風格，會增加代碼閱讀和維護的複雜度。
