本文探討程式設計中的一個術語：“可讀性”。
首先我們來談談它的含義：
“可讀性”是描述在其他開發人員沒有進行太多聯想或猜測的情況下就能理解程式碼的含義。為了讓其他的開發者對你的程式碼“可讀”，你需要謹慎選擇每個變數命名甚至是引數命名。
但是有些東西是普遍存在而且也是受到人為因素的限制的。例如，很少會有開發者去追蹤命名不定的變數。
啟發：變數，類，方法和其他引用是否有明確的名稱？
或者從開發者本身的角度看，這些開發人員是否熟悉正在接管的專案程式碼？他們作為開發人員有多經驗？他們是否有特定的背景使得程式碼對他們有或多或少的可讀性？
但是我們通常會遇到這樣的應用場景：你並不知道其他開發者是誰？這在開源專案中最為普遍。
所以這就是我們在程式設計中制定標準，模式和最佳實踐的原因。例如，JavaScript 程式碼傾向於使用 camelCase （駝峰命名），因此使用 camelCase 編寫程式碼可以提供流暢的感覺（這就可以起到可讀性的作用）。瞭解一門語言通常使用的常見模式和風格非常重要。
補充：你所在的團隊可能會制定一些自己的程式設計規定; 這個時候請你遵循它。
以下是可以遵循的一些簡單而實用的方法：
- 儘量使用描述性變數名稱。 更長的變數一般更具有可讀性。
- 使用空格！ 程式碼編譯器的存在意味著空格對於程式碼執行來說是無關緊要的的，但是空格對於人來說，確實很重要！所以要利用好這一個優勢。
- 在抽象和實用性之間找到一個平衡點。 比如最簡單的任務不需要 10 層重定向; 而是要從最簡單的方法開始，在重構過程中進行抽象。
- “讓程式碼跑起來，然後跑得對，最後跑得快。” 注意遵守這個順序。 這將極大地幫助你提高程式碼的可讀性，因為你首先從理解開始，然後轉向效能。 這就預先建立了你的模式和語義，你更有可能以這種方式保持良好的語義化。
- 瞭解你的受眾。 如果你的受眾不習慣內聯的 lambda 計算，請不要使用它。 即使您認為這是解決問題的“最佳途徑”，但還有其他同樣可行的方法。
- 遵循完善的重構和麵向物件的模式。講真， 這些概念都是前輩嘗試和測試過的，你可以先不用懷疑太多，先準守它。
- 但是！也不要盲目遵守規則。 不定期地花些時間去重新審視程式碼：有沒有什麼東西很奇怪？ 這混淆了什麼麼？ 這樣寫是不是更好？
- 可讀性高的程式碼不總是易於維護的，反之亦然。 可維護的程式碼通常是遵循良好的實踐和原則建立起來的。
- 測試對程式碼庫維護非常重要！擁有良好的測試覆蓋率使您不必將所有程式碼記在您的腦海中。 （注意：測試不會一起消除錯誤，但是測試對你的幫助非常大。）
總而言之，程式設計是一個人為的過程。 在編寫程式碼時遵循下面的建議:
更簡單通常會更好 —海明威。