十個好習慣，讓你的代碼更容易閱讀

Jason McCreary 原做，受權 New Frontend 翻譯。

我已經寫了二十年代碼了，這期間我在十七個團隊用不一樣語言寫了幾百個項目，其中不只有簡單的博客站點，還有支撐每秒 3000 次請求的 API 服務，以及不少熱門應用。

經過這些經歷，加上一些我讀過的書，我總結出了寫代碼時最須要關注的東西：可讀性。

表面上來看，可讀性是個很主觀的東西，它跟語言、代碼庫、團隊都有關係。可是若是你深刻研究的話，就會發現其實有不少不管什麼代碼都能用到的提高可讀性的方法。

不少程序員寫代碼時只會在乎「機器」的那一面：只要代碼能運行，其餘的就無論了。這最終形成了「人」的那一面被忽視掉了。

在過去幾個月裏，我把有關「人」的那一面總結成了下面十個能讓你專一於編寫簡單、可讀代碼的好習慣。我在 BaseCode 裏面對每一條都進行了詳細解釋，並把它們應用到了真實世界的代碼片斷上。

然而不少人仍是會對它們嗤之以鼻，以爲這些都太基本了，不值得關注。可是我能夠保證，每個我接觸到的低質量的代碼都沒能達到這些要求，而每個你能讀到的高質量的代碼，即使作不到大部分，也都至少能作到其中一點。

---

格式化

咱們平時花了太多精力來格式化代碼：用 tab 仍是用空格、換行大括號仍是大括號換行等等。有一天你會忽然發現，寫代碼的時候其實不該關注如何去格式化。最好的作法仍是爲整個代碼庫選擇一個標準，而後讓一切自動化，這樣你就能把精力從新放回寫代碼自己了。

無用代碼

全部被註釋掉的代碼、沒有用到的變量、程序不會通過的代碼都是廢物。它們時時刻刻在向讀代碼的人傳遞着「個人主人不在意我」這樣的信息。代碼庫裏一旦有了這樣的代碼，惡性循環就開始了。漸漸地，這些無用代碼會讓你的代碼庫變成一個爛攤子，這跟破窗效應差很少。因此你必須時常檢查並清理無用代碼。即便不把它看成主要任務，至少你也應該作一名童子軍。

多重嵌套代碼

幾乎全部的代碼都是基於邏輯產生的。咱們經過代碼來產生決策、構造重複、執行計算，這每每會致使代碼中存在不少層級。儘管計算機能夠很輕易地理清這一切，然而對於人類來講就困難多了。過多的嵌套會讓代碼看起來更復雜且難以閱讀。要解決這個問題，能夠經過使用衛語句、提早返回、函數式編程的方法把代碼鋪平開來。

對象的使用

儘管如今是一個面向對象編程的時代，但咱們仍是會沉迷於原始的方法。咱們會寫很長的參數列表，把全部數據堆在一塊兒，或是本身定義數組和字典的結構。其實這些東西均可以被重構成多個對象。這麼作不只讓數據更加結構化，還能夠整理出會反覆用到的操縱原始數據的邏輯。

大型代碼塊

儘管並無一個明確的數字，但代碼塊仍是應該小於某個長度的。若是你知道你的代碼裏有較大的代碼塊，你能夠把它找出來，而後從新組織它或者是重構它。這個簡單的過程能讓你認識到代碼塊的上下文以及抽象等級，這樣你就能夠正確地認清代碼塊的做用並將其重構爲多個更簡單、更可讀的代碼塊。

命名

命名確實很難，不過這僅僅是由於咱們把它弄複雜了。其實有一個小技巧能夠運用在包括命名在內的不少編程難題上：推遲。遇到命名難題時，不要卡在上面，而是要繼續前進。若是有須要的話，能夠先用一句話來命名一個變量。我能夠保證在你完成一個功能或是整個項目的時候，你天然會想到一個合適的名字。

註釋的清理

這個小小的習慣徹底改變了個人編程生涯，讓我真正開始關注代碼的可讀性。儘管我解釋了一遍又一遍，仍是會有人由於這個而討厭我。他們總能拿出一個例子來證實註釋是絕對有用的。確實，假如哈勃望遠鏡的遙測系統就是須要經過返回 687 這個值來跟一個古老的適配器進行交流，那麼代碼旁邊的註釋仍是有用的。可是對於大多數其餘狀況來講，你應該試着重寫代碼，爭取讓讀代碼的人不靠註釋就能理解它。

合理的返回值

咱們老是愛返回各類奇奇怪怪的值（像 -1、687、null），尤爲是遇到邊界狀況的時候。反過來，又寫了不少代碼去處理這些值。實際上，發明 null 的人把它形容爲十億美圓的損失。你應該儘量返回有意義的值，最好是在即便方法內部出錯的狀況下還能讓剩餘的代碼繼續正常執行。若是確實有例外狀況，必定有比直接返回 null 更好的交流方式。

三的法則

假設存在一串數字，我告訴你第一個是 2，而後問你後面是幾，你可能會說 3 跟 4，但也有多是 1 或 2.1（其實真要問你的話，你可能毫無頭緒）。這時我額外給你一個數字，問你 2, 4 後面是幾，你可能會說 6 或 8 或 16（儘管答案更加肯定，不過仍是有點茫然）。這時我再給你一個數字，問你 2, 4, 16 後面是幾，這時做爲程序員的你確定能看出數字間平方的關係，而後肯定出下一個數字是 256。這就是「三的法則」。

上面這個不包含代碼的例子其實告訴咱們不要過早地決定一種抽象或設計方式。三的法則就是要咱們克服想去減小重複的需求，把它推遲到有足夠數據去支撐決策的時候。用 Sandi Metz 的話來講，就是「錯誤的抽象付出的代價要比重複更多」。

對稱性

用好了這一條，你的代碼就能增添幾分詩同樣的可讀性。Kent Beck 的《Implementation Patterns》中這樣寫道：

代碼裏面的對稱性就是指同一個主意在不一樣地方都以同一種方式表達。 不過提及來容易作起來難，對稱性其實蘊含了創造性寫做的色彩。它構成了命名、結構、對象、模式等方面的基礎，並且在不一樣語言、代碼庫、團隊之間也會有所不一樣。照這麼說，你大概須要用一生的生命去追求它。因此，當你開始在代碼裏運用對稱性以後，一個更乾淨的形態就會產生，而且你的代碼會更快成型。

---

以上是對 BaseCode 裏面提到的習慣的概述。我建議你去瀏覽這篇文章裏連接到的資源，觀看實踐這些習慣的錄像，或者去 BaseCode 裏面詳細閱讀如何在真實世界的代碼片斷中運用這些習慣。

Photo by Edu Lauton on Unsplash