易讀程式之美學：提升程式碼可讀性的簡單法則

　　本書主題是介紹如何寫出有高度可讀性的程式碼，主要概念是程式碼必需易於理解，更精 確地說，撰寫程式碼時應將他人理解程式碼所需的時間縮到最短。

　　本書使用許多不同程式語言的範例解釋這個概念，包含了 C++、Python、JavaScript 以及 Java；避開了程式語言的進階特性，即使不熟悉這些程式語言的讀者，也能夠輕易理解內 容（畢竟，可讀性概念大多與程式語言本身無關）。

　　本書各章節由程式設計的不同層面說明如何讓程式「更易於理解」，共分為四個部份；

　　表層改善
　　名稱、註解與美學：使用在每一行程式碼的簡單技巧。

　　簡化迴圈與邏輯
　　透過改善程式的迴圈、邏輯與變數，提高可讀性的方法。

　　重新組織程式碼
　　組織大區塊程式以及從函數層面解決問題的高階作法。

　　精選主題
　　將「易於理解」原則應用在測試以及大型資料結構的程式。

作者簡介

Dustin Boswell

　　畢業於 CalTech，任職於 Google 五年，負責網頁抓取基礎設施（web crawling infrastructure）以及廣告相關程式。他建立了多個網站，喜歡海量資料與機器學習等領域。

Trevor Foucher

　　曾任職於微軟十餘年，擔任 Windows 與安全相關產品的工程師、經理以及技術負責人，目前任職於 Google 負責廣告程式與搜尋基礎設施。

第一章

程式碼應該易於理解

過去五年，作者們收集了數百個「不良程式碼」（大多數是自己寫的），分析造成不良的原 因，找出改善的原則與技巧，最後發現所有的原則都回溯到相同的概念。

重要概念

程式碼應該易於理解。

作者們相信這是寫程式時最重要的原則，接下來的內容，會將這個原則應用在程式設計師 每天工作的各個層面，首先詳細說明這個原則以及最為重要的原因。

「更好」的意義？ 大多數程式設計師（包含作者在內）根據直覺選擇呈現程式碼的方式，大家都知道（即使 下面範例中的程式碼有完全相同的行為），但這種寫法：

for (Node * node = list->head; node != NULL; node = node->next) Print(node->data);

比起以下的寫法來得好：

Node* node = list->head; if (node == NULL) return;

while (node->next != NULL) { Print(node->data);
node = node->next;
}
if (node != NULL) Print(node->data);

但很多時候，決定何者要好並不容易，例如這段程式：

return exponent >= 0 ? mantissa * (1 << exponent) : mantissa / (1 << -exponent);

是否比這種寫法來得好：

if (exponent >= 0) {
return mantissa * (1<< exponent);
} else {
return mantissa / (1 << -exponent);
}

第一個版本比較簡潔，第二個版本則較容易瞭解，那個條件比較重要？一般來說，該如何 決定程式碼的呈現方式？

可讀性基本定理 看了許許多多的範例之後，得到的結論是，存在一個最為重要的可讀性指標，重要到能夠 將之稱為「可讀性基本定理」。

重要概念

撰寫程式時應該將讀者理解所需的時間降到最短。

這是什麼意思？很簡單，找個一般的能力的同事，測量他們理解程式碼需要的時間，這就 是撰寫程式時希望縮短的理論值。

「理解」的要求非常高，完全理解 程式碼，應該要能夠修改、找出臭蟲並知道與程式其 他部份互動的方式。

現在，讀者可能認為，「誰會在乎其他人懂不懂？我是唯一一個使用這些程式碼的 人！」即使單人專案也值得追求這個目標，「其他人」可能是六個月後的自己，到時候對 程式碼不再熟悉。永遠無法確定 ── 可能有其他人加入專案，或是「被丟棄的程式碼」
可能被用在其他專案當中。

比較短的程式都比較好嗎？

一般來說，解決問題所需的程式碼愈短愈好（參看第十三章，撰寫較少程式碼），瞭解一 個由 2000 行程式碼的類別所需時間可能比由 5000 行程式碼的類別來得短。

但較少的程式碼並非總是比較好！很多時候像這樣的單行表示式：

assert((!(bucket = FindBucket(key))) || !bucket->IsOccupied())

比起兩行的寫法需要更多時間理解：

bucket = FindBucket(key)
if (bucket != NULL) assert(!bucket->IsOccupied());

同樣的，註解雖然會在檔案中「加入更多程式」，卻能讓人更快速的理解程式碼：

// hash = (65599 * hash) +c 的快速版
hash = (hash << 6) + (hash << 16) - hash + c;

雖然減少程式碼數量是個很好的目標，但縮短理解時間更加重要。

最短理解時間是否與其他目標衝突？ 讀者可能會想「其他的條件怎麼辦？像是程式效率、良好的架構或是可測試性等等？這些 條件難道不會和讓程式易於瞭解的原則衝突嗎？」

作者發現其他目標並不會受到太大的影響，即使在高度最佳化的程式碼中，仍然有辦法讓 程式碼具有高度可讀性；實際上讓程式碼易於瞭解常常也會產生良好的架構且易於測試。

本書接下來將介紹如何在各種情況應用「易於閱讀」，切記，難以決定時，可讀性基本定 理優於本書所提的其他任何原則。同時，某些程式設計師無法忍受任何不夠完美的程式 碼，這時必須停下腳步，想想 程式碼是否易於理解？」如果已經如此，也許可以放心處
理其他的程式碼。

困難所在 的確，時時考慮某個虛擬讀者是否能夠理解程式碼需要花費不少額外的功夫，需要將大腦 切換到撰寫程式時沒有用到的部份才行。

但如果（和作者一樣）選擇了這個目標，可以確定讀者將會成為更好的程式設計師，產 生更少的臭蟲，對成品更有認同感，同時能產出其他人樂於使用的程式碼，就讓我們開 始吧！

第五章

認識註解

本章介紹程式碼中的註解，許多人認為註解只是「解釋程式碼行為」，但那只是其中一小 部份。

重要概念

註解的目的是協助使用者瞭解程式碼作者的思想。

撰寫程式時，程式設計師腦中有許多寶貴的資訊；其他人閱讀程式碼時少了這些資訊
── 只剩下眼前的程式碼。

本章提供許多範例，說明何時該寫下腦中的資訊，略過一般的註解，集中在更為有趣以及 註解「較為不足」的部份。

本章內容組織為以下幾個部份：

z 瞭解不該註解的部份。

z 記錄撰寫程式時的想法。

z 為讀者設身處地，想像讀者需要知道的東西。

不該註解的部份

閱讀註解會佔用閱讀程式碼的時間，註解也會佔用畫面上的空間，因此註解必須有價值； 該如何區分有價值的註解與沒必要的註解？

下列程式中所有的註解都沒有必要：

// Account 的類別定義
class Account { public:
// 建構子
Account();
// 將 profit 成員設為新值
void SetProfit(double profit);

// 傳回這個 Account 的 profit
double GetProfit();
};

這些註解既沒有提供任何額外的資訊，也無法讓人進一步瞭解程式碼，所以沒有必要。