為什麼我要垂直對齊程式碼(你也要如此!)

發表於2015-11-27

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

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

什麼是垂直對齊?

舉個小例子:

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

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

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

理解

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

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

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

考慮下面的程式碼:

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

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

為什麼使用等寬字型?

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

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

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

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

我們沒有工具

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

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

——Andreas van Cranenburgh

……還有……

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

——scrollaway

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

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

By Nick Gravgaard

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

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

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

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

註釋

  1. 90-90 法則(ninety-ninety rule,九九定律,99 定律)是計算機程式設計和軟體工程領域的一個有名的法則,出自於一句幽默的格言:(開發軟體時)前 90% 的程式碼要花費 90% 的開發時間,剩餘的 10% 的程式碼要再花費 90% 的開發時間。維基百科解釋
  2. 等寬字型(Monospaced Font)是指字元寬度相同的電腦字型。與此相對,字元寬度不盡相同的電腦字型稱為比例字型。在等寬字型中,字母i,j顯得兩側餘白較多,而字母w,m等的筆畫顯得相當擁擠。但是隨著圖形使用者介面主流的更新和電腦技術的提高,處理比例字型的侷限性得到了突破,因此現在排版上顯得比較自然的比例字型的使用已經相當普及。另外,程式碼也經常使用等寬字型。維基百科解釋
  3. 比例字型(Proportional Font)是指字元寬度不盡相同的電腦字型。與此相對,字元寬度相同的電腦字型稱為等寬字型。維基百科解釋

相關文章