Steve Freeman

程式碼排版的重要性#

多年前，作者在一個 Cobol 系統工作，那裡的員工不被允許更改縮排，除非他們已經有理由修改程式碼。因為曾經有人不小心讓一行滑進了行首的特殊欄位而造成了問題。這意味著即使排版有誤導性，他們也必須非常仔細地閱讀程式碼，因為無法信任排版。這個政策在程式設計師的生產力上一定造成了巨大的損失。

我們花更多時間在閱讀而非打字#

研究顯示，我們在程式設計時花費更多時間在瀏覽和閱讀程式碼——尋找要修改的地方——而不是在打字。因此，我們要優化的是閱讀體驗。以下是三種優化方式：

容易掃視（Easy to Scan）#

人類非常擅長視覺模式匹配（這是我們在草原上辨認獅子的遺留特徵）。你可以把所有與領域無直接關聯的東西——大多數商業程式語言附帶的**「偶然複雜性（accidental complexity）」**——透過標準化來淡化到背景中。如果外觀相同的程式碼行為也相同，那麼你的感知系統就能幫你辨認出差異。這也是為什麼作者遵循在編譯單元中如何排列 class 各部分的慣例：常數、欄位、公開方法、私有方法。

表達性排版（Expressive Layout）#

我們都學過要花時間為程式碼選擇正確的命名，讓它盡可能清楚地表達它做什麼，而不只是列出步驟——對吧？程式碼的排版也是表達性的一部分。第一步是讓團隊同意使用自動格式化工具處理基本格式，然後在編寫時手動微調。除非有激烈分歧，團隊會很快收斂出共同的「手工完成」風格。格式化工具無法理解作者的意圖，而對作者來說，換行和分組反映程式碼的意圖比只是反映語法更重要。

緊湊格式（Compact Format）#

螢幕上能看到越多內容，就能在不中斷上下文的情況下看到越多——不需要捲動或切換檔案，也就能在腦中保持更少的狀態。過去那些長篇的程序註解和大量空白在八字元變數名和列印機的時代是合理的，但現在我們在有語法高亮和交叉連結的 IDE 中工作。像素是我的限制因素，我希望每一個像素都對我理解程式碼有所貢獻。排版應該幫助我理解程式碼，但僅此而已。

一位非程式設計師朋友曾說，好的程式碼看起來像詩——文字中的每樣東西都有其目的，都是為了幫助讀者理解。不幸的是，寫程式碼不像寫詩那麼浪漫。