為什麼我要垂直對齊程式碼

上週在 HackerNews，關於 Linux Kernel 程式碼風格展開了有趣的討論。

在討論中，我就應不應該垂直對齊程式碼發起了一場小小的聖戰。我完全支援！讓我細說端詳。

（題圖來自： yogizendude.com）

什麼是垂直對齊？

舉個小例子：

int robert_age = 32;
int annalouise_age = 25;
int bob_age = 250;
int dorothy_age = 56;

下面的程式碼更易於閱讀：

int robert_age     = 32;
int annalouise_age = 25;
int bob_age        = 250;
int dorothy_age    = 56;

我掃一眼就能看到”bob_age”有點兒不正常。我不用多費事，就輕鬆地看出來它們都是整數。

這條意見還沒被廣為分享，因此我打算解釋一下，為什麼很多人認為這是一種有用的風格指南。

理解

90% 的程式設計工作是為了解決問題，剩下的 10% 的工作需要再用 90% 的時間用來理解問題是怎樣被解決的。

閱讀程式碼和閱讀散文，有著極大的不同。我們期望作者能夠清晰地解釋他們的語句，而不是用他們選中的語言過於冗長地說些不相干的東東，我們都期待普通的語法風格。

的確，Kernel 程式碼風格著重強調了這一點。你選擇變數命名的方式，和程式碼的用途一樣重要。

考慮下面的程式碼：

var thinG=doIt(thestuff,MORE_sTuff); /* LOL! */

即便你對程式碼庫有深入理解，它也不是特別易讀的程式碼行。

var totalBill = apply_tax(initialBill, taxRate);

對於清晰的應用程式，要藉助命名習慣、間隔和大寫，從而讓程式碼更易於閱讀。這意味著，接手我們程式碼的可憐傢伙，將用更少的時間來解密程式碼，把更多時間放在理解上面。

為什麼使用等寬字型？

在所有著名的、老生常談的舌戰中，有兩個實力基本相當的陣營，即等寬字型 VS 比例字型的爭論。

某些異教徒會對你說，比例字型是最棒的——無視這些異教徒吧。另一些異教徒則在他們爭論比例字型所具有的上等純潔度時，給你的心靈留下了不和諧——這些可憐的、受譴責的靈魂呀。

最終，還要歸結到可讀性。你覺得，什麼東西能夠最容易地幫助你理解程式碼？為什麼 IDE 有著色方案——因此你能一眼看出“foo”是函式、常量、變數還是註釋。只要能讓你更快地理解這段程式碼的用途，它就是好的東西！

這也是電子表格如此受歡迎的原因之一。列提高了可讀性。你可以快速地順著一列掃視，並能注意到某行和其它行是否存在明顯不同。

我們沒有工具

有趣的是，在 HackerNews 上的討論中，我面臨的最大批評與垂直對齊是否有用無關，而是我們的工具有多麼糟糕。

「這破壞了 diff 的可讀性和可用性。比如你修改了某個常量，需要快速追蹤因此引起的嚴重 bug。對於水平排列的程式碼，diff 或許包含了所有修改過的行，從而掩蓋了關鍵修改。有一些忽視空格的變通方案，以及基於單詞的 diff，不過依本人愚見，不值得這麼麻煩。
——Andreas van Cranenburgh

……還有……

假如你有 50 行賦值語句，你把所有值都和最大的那個對齊了，那麼增加一個賦值語句，將迫使你更新 50 行程式碼。我已經遇到過這些情形了，每當那時候，我就明白了，不要那樣對齊值 是多麼地重要。
——scrollaway

這些論點在某些語境中是合理的，但是說明了需要更好的工具。

我想起了 Elastic Tabstops ——自動排列程式碼塊的方法。

工具能夠輕鬆容納這種工作方式。計算機就是為我們做單調、重複工作的，CPU 週期「浪費」在讓程式碼更可讀方面的代價，已經足夠便宜了。

在 Linux Kernel 中，還有大量的例子，垂直排列讓程式碼更便於人類分析。

垂直排列不適用於每個場景，但是對於快速評估程式碼，其可讀性是無與倫比的。

程式碼是具有創造性的平臺，我們通過這個平臺來表達想法。如果工具增加了理解這些想法的難度，那麼，需要改變的就是工具、而非我們。