編寫可讀的程式碼

來源：《程式設計師》

程式碼最重要的讀者不再是編譯器、直譯器或者電腦，而是人。寫出的程式碼能讓人易於理解、輕鬆維護、容易擴充套件的程式設計師才是專業的程式設計師。

程式碼應當易於理解

在過去的五年裡，我們收集了上百個“壞程式碼”的例子（其中很大一部分是我們自己寫的），並且分析是什麼原因使它們變壞，使用什麼樣的原則和技術可以讓它們變好。我們發現所有的原則都源自同一個主題思想。

關鍵思想：程式碼應當易於理解

我們相信這是當你考慮要如何寫程式碼時可以使用的最重要的指導原則。我們會展示如何把這條原則應用於你每天編碼工作的各個不同方面。但在開始之前，我們會詳細地介紹這條原則並證明它為什麼這麼重要。

是什麼讓程式碼變得“更好”

大多數程式設計師（包括兩位作者）依靠直覺和靈感來決定如何程式設計。我們都知道這樣的程式碼：

比下面的程式碼好：

（儘管兩個例子的行為完全相同。）但很多時候這個選擇會更艱難。例如，這段程式碼：

它比下面這段要好些還是差些？

第一個版本更緊湊，但第二個版本更直白。哪個標準更重要呢？一般情況下，在寫程式碼時你如何來選擇？

可讀性基本定理

在對很多這樣的例子進行研究後，我們總結出，有一種對可讀性的度量比其他任何的度量都要重要。因為它是如此重要，我們把它叫做“可讀性基本定理”。

關鍵思想：程式碼的寫法應當使別人理解它所需的時間最小化。

這是什麼意思？其實很直接，如果你叫一個普通的同事過來，測算一下他通讀你的程式碼並理解它所需的時間，這個“理解程式碼時間”就是你要最小化的理論度量。

並且當我們說“理解”時，我們對這個詞有個很高的標準。如果有人真的完全理解了你的程式碼，他就應該能改動它、找出缺陷並且明白它是如何與你程式碼的其他部分互動的。

現在，你可能會想：“誰會關心是不是有人能理解它？我是唯一使用這段程式碼的人！”就算你從事只有一個人的專案，這個目標也是值得的。那個“其他人”可能就是 6 個月的你自己，那時你自己的程式碼看上去已經很陌生了。而且你永遠也不會知道——說不定別人會加入你的專案，或者你“丟棄的程式碼”會在其他專案裡重用。

總是越小越好嗎

一般來講，你解決問題所用的程式碼越少就越好。很可能理解 2000 行程式碼寫成的類所需的時間比 5000 行的類要短。但少的程式碼並不總是更好！很多時候，像下面這樣的一行表示式：

理解起來要比兩行程式碼花更多時間：

類似地，一條註釋可以讓你更快地理解程式碼，儘管它給程式碼增加了長度：

因此儘管減少程式碼行數是一個好目標，但把理解程式碼所需的時間最小化是一個更好的目標。

理解程式碼所需的時間是否與其他目標有衝突

你可能在想：“那麼其他約束呢？像是使程式碼更有效率，或者有好的架構，或者容易測試等？這些不會在有些時候與使程式碼容易理解這個目標衝突嗎？”我們發現這些其他目標根本就不會互相影響。就算是在需要高度優化程式碼的領域，還是有辦法能讓程式碼同時可讀性更高。並且讓你的程式碼容易理解往往會把它引向好的架構且容易測試。有些程式設計師對於任何沒有完美地分解的程式碼都不自覺地想要修正它。這時很重要的是要停下來並且想一下：“這段程式碼容易理解嗎？”如果容易，可能轉而關注其他程式碼是沒有問題的。

最難的部分

是的，要經常地想一想其他人是不是會覺得你的程式碼容易理解，這需要額外的時間。這樣做就需要你開啟大腦中從前在編碼時可能沒有開啟的那部分功能。但如果你接受了這個目標（像我們一樣），我們可以肯定你會成為一個更好的程式設計師，會產生更少的缺陷，從工作中獲得更多的自豪，並且編寫出你周圍人都愛用的程式碼。

本文節選自《編寫可讀程式碼的藝術》一書，Dustin Boswell、Trevor Foucher 著，尹哲、鄭秀雯譯，由機械工業出版社出版。