代碼可讀性隨想

原文： https://www.codecasts.com/blo...

本文探討編程中的一個術語：「可讀性」。

首先咱們來談談它的含義：

「可讀性」是描述在其餘開發人員沒有進行太多聯想或猜想的狀況下就能理解代碼的含義。爲了讓其餘的開發者對你的代碼「可讀」，你須要謹慎選擇每一個變量命名甚至是參數命名。

可是有些東西是廣泛存在並且也是受到人爲因素的限制的。例如，不多會有開發者去追蹤命名不定的變量。

啓發：變量，類，方法和其餘引用是否有明確的名稱？

或者從開發者自己的角度看，這些開發人員是否熟悉正在接管的項目代碼？他們做爲開發人員有多經驗？他們是否有特定的背景使得代碼對他們有或多或少的可讀性？

可是咱們一般會遇到這樣的應用場景：你並不知道其餘開發者是誰？這在開源項目中最爲廣泛。

因此這就是咱們在編程中制定標準，模式和最佳實踐的緣由。例如，JavaScript 代碼傾向於使用 camelCase （駝峯命名），所以使用 camelCase 編寫代碼能夠提供流暢的感受（這就能夠起到可讀性的做用）。瞭解一門語言一般使用的常見模式和風格很是重要。

補充：你所在的團隊可能會制定一些本身的編程規定; 這個時候請你遵循它。

如下是能夠遵循的一些簡單而實用的方法：

1. 儘可能使用描述性變量名稱。 更長的變量通常更具備可讀性。
2. 使用空格！ 代碼編譯器的存在乎味着空格對於代碼執行來講是可有可無的的，可是空格對於人來講，確實很重要！因此要利用好這一個優點。
3. 在抽象和實用性之間找到一個平衡點。 好比最簡單的任務不須要 10 層重定向; 而是要從最簡單的方法開始，在重構過程當中進行抽象。
4. 「讓代碼跑起來，而後跑得對，最後跑得快。」 注意遵照這個順序。 這將極大地幫助你提升代碼的可讀性，由於你首先從理解開始，而後轉向性能。 這就預先創建了你的模式和語義，你更有可能以這種方式保持良好的語義化。
5. 瞭解你的受衆。 若是你的受衆不習慣內聯的 lambda 計算，請不要使用它。 即便您認爲這是解決問題的「最佳途徑」，但還有其餘一樣可行的方法。
6. 遵循完善的重構和麪向對象的模式。講真， 這些概念都是前輩嘗試和測試過的，你能夠先不用懷疑太多，先準守它。
7. 可是！也不要盲目遵照規則。 不按期地花些時間去從新審視代碼：有沒有什麼東西很奇怪？ 這混淆了什麼麼？ 這樣寫是否是更好？
8. 可讀性高的代碼不老是易於維護的，反之亦然。 可維護的代碼一般是遵循良好的實踐和原則創建起來的。
9. 測試對代碼庫維護很是重要！擁有良好的測試覆蓋率使您沒必要將全部代碼記在您的腦海中。 （注意：測試不會一塊兒消除錯誤，可是測試對你的幫助很是大。）

總而言之，編程是一我的爲的過程。 在編寫代碼時遵循下面的建議:

更簡單一般會更好 —海明威。