資訊專欄INFORMATION COLUMN
摘要：例如，代碼傾向于使用駝峰命名，因此使用編寫代碼可以提供流暢的感覺這就可以起到可讀性的作用。這將極大地幫助你提高代碼的可讀性，因為你首先從理解開始，然后轉向性能。
原文：https://www.codecasts.com/blo...
本文探討編程中的一個術語：“可讀性”。
首先我們來談談它的含義：
“可讀性”是描述在其他開發人員沒有進行太多聯想或猜測的情況下就能理解代碼的含義。為了讓其他的開發者對你的代碼“可讀”，你需要謹慎選擇每個變量命名甚至是參數命名。
但是有些東西是普遍存在而且也是受到人為因素的限制的。例如，很少會有開發者去追蹤命名不定的變量。
啟發：變量，類，方法和其他引用是否有明確的名稱？
或者從開發者本身的角度看，這些開發人員是否熟悉正在接管的項目代碼？他們作為開發人員有多經驗？他們是否有特定的背景使得代碼對他們有或多或少的可讀性？
但是我們通常會遇到這樣的應用場景：你并不知道其他開發者是誰？這在開源項目中最為普遍。
所以這就是我們在編程中制定標準，模式和最佳實踐的原因。例如，JavaScript 代碼傾向于使用 camelCase （駝峰命名），因此使用 camelCase 編寫代碼可以提供流暢的感覺（這就可以起到可讀性的作用）。了解一門語言通常使用的常見模式和風格非常重要。
補充：你所在的團隊可能會制定一些自己的編程規定; 這個時候請你遵循它。
以下是可以遵循的一些簡單而實用的方法：
盡量使用描述性變量名稱。 更長的變量一般更具有可讀性。
使用空格！ 代碼編譯器的存在意味著空格對于代碼執行來說是無關緊要的的，但是空格對于人來說，確實很重要！所以要利用好這一個優勢。
在抽象和實用性之間找到一個平衡點。 比如最簡單的任務不需要 10 層重定向; 而是要從最簡單的方法開始，在重構過程中進行抽象。
“讓代碼跑起來，然后跑得對，最后跑得快。” 注意遵守這個順序。 這將極大地幫助你提高代碼的可讀性，因為你首先從理解開始，然后轉向性能。 這就預先建立了你的模式和語義，你更有可能以這種方式保持良好的語義化。
了解你的受眾。 如果你的受眾不習慣內聯的 lambda 計算，請不要使用它。 即使您認為這是解決問題的“最佳途徑”，但還有其他同樣可行的方法。
遵循完善的重構和面向對象的模式。講真， 這些概念都是前輩嘗試和測試過的，你可以先不用懷疑太多，先準守它。
但是！也不要盲目遵守規則。 不定期地花些時間去重新審視代碼：有沒有什么東西很奇怪？ 這混淆了什么么？ 這樣寫是不是更好？
可讀性高的代碼不總是易于維護的，反之亦然。 可維護的代碼通常是遵循良好的實踐和原則建立起來的。
測試對代碼庫維護非常重要！擁有良好的測試覆蓋率使您不必將所有代碼記在您的腦海中。 （注意：測試不會一起消除錯誤，但是測試對你的幫助非常大。）
總而言之，編程是一個人為的過程。 在編寫代碼時遵循下面的建議:
更簡單通常會更好 —海明威。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/94827.html
摘要：背景如圖所示馮諾依曼計算機體系結構由于最近做業務需求做到發瘟借此發散一下思維最近業務需求的痛點如下基礎代碼骨架已固定業務流程固定然而業務中產品的配置需要非常靈活并且有可能需要跨過某段業務流程直接執行下一段直接方案當然是能夠決定條件分支的但架 showImg(https://segmentfault.com/img/bVbrHbo?w=1920&h=981); 背景 如圖所示, 馮諾依曼...
摘要：前面不短時間持續投入了時間在做應用架構方面的考量一個是冒險進行了一次應用架構的調整另一個是跟進了的進展當然實際上是同一個事情也許錯過的比收獲的還多一些不過能走到現在也算幸運了畢竟單頁面應用還面臨很多不成熟之處國慶長假過去不少現在的想法估計會 前面不短時間持續投入了時間在做 React 應用架構方面的考量一個是冒險進行了一次應用架構的調整, 另一個是跟進了 Redux 的進展當然, 實際...
閱讀 1702·2021-11-25 09:43
閱讀 2665·2019-08-30 15:53
閱讀 1808·2019-08-30 15:52
閱讀 2898·2019-08-29 13:56
閱讀 3317·2019-08-26 12:12
閱讀 565·2019-08-23 17:58
閱讀 2127·2019-08-23 16:59
閱讀 932·2019-08-23 16:21
