較近經(jīng)常提出什么是代碼可讀性（通常作為神秘 DX 的一部分）的問題。越來越多的人開始說可讀性純粹是一個偏好問題。我不能責怪他們。經(jīng)過多年的發(fā)展，我們可能會認為我們已經(jīng)完全有能力感知不同質(zhì)量、范式和語言的不同代碼。我們也可以習慣那些起初讓我們覺得不舒服的工具。并得出結(jié)論：一切都取決于經(jīng)驗！嗯，是的，也不是。

這是一把雙刃劍

佐丁較近表示：這種質(zhì)量有兩個目的——代碼的可讀性和可維護性如何，以及程序員的熟練程度如何

你知道，我對這個觀點有些滿意。它本可以就此打住，但后來 Tsodin 對程序員本身進行了更多的掩蓋，并將一切都簡化為廣義的“git gud”。

這個說法的問題在于，我們有點含蓄地說——任何代碼都是可讀的，只是你沒有足夠的技能！老實說：并非所有代碼本身都是可讀的。

哦，但是你能定義什么是可讀性嗎？

您可能經(jīng)常聽到這樣的問題：“您能定義可讀性嗎？不，不，不僅僅是可讀性，還有代碼可讀性，這是完全不同的，你知道。»

事實上，根據(jù)定義，可讀性分為多文字表現(xiàn)和文本的語言特征。但我們不是來評估字體或連字對代碼可讀性的貢獻，對嗎？

我們真正感興趣的是代碼的語言方面：

• 命名；
• 句法結(jié)構(gòu)的復雜性；
• 抽象程度；
• ETC。

“是的，這些都是偏好。” 不，他們不是。因為代碼和文本之間有一個重要的區(qū)別：與文本不同，代碼有義務實現(xiàn)其意圖。文本是否達到其目的實際上并不那么重要。例如，作者試圖通過文本傳達的想法或概念。如果他們不喜歡，那么，這只是一個糟糕的文本。它仍然在那里，文字是相關的，只是不善于表達思想。但代碼必須解決預期的問題，否則它就是字面意義上的錯誤且不適用。不好≠錯誤。

所有這些可能使我們相信代碼可讀性實際上是一種復合現(xiàn)象：

• 它包括問題的正確解決方案；
• 它完整??地描述了工作算法（即，它實際上并沒有對我們的意圖撒謊；）
• 并且這個解決方案的可讀性較大程度地與問題本身成正比。
• 

代碼可讀性并不是你想象的那樣

請注意我們?nèi)绾螐?ldquo;代碼可讀性”切換到“解決方案可讀性”？我相信這是表征可讀性問題的主要特征：我們試圖在沒有上下文的情況下看待這個術語。當我們嘗試判斷代碼的可讀性時，許多人主要判斷代碼本身，而不是它試圖解決的問題。這就是爭論開始的地方：過程性代碼比函數(shù)式代碼更具可讀性，聲明性代碼比命令性代碼更清晰，繼承與組合以及一堆其他流行語。

您的編碼風格可能對您來說更具可讀性，但這并不意味著它可以形成可讀的解決方案。

現(xiàn)在，讓我們看一下非常簡單（mb 太簡單）的示例：

def calculate(bottom, top)
  return 0 if top < bottom
  sum = 0
  for number in bottom..top do
    next unless number % 2 == 0
    sum += number
  end
  sum
end

和

def calculate(bottom, top)
  (bottom..top).select(&:even?).sum
end

愚蠢的例子，對吧？但什么樣的代碼更具可讀性呢？你們中有些人會說兩者都非?？勺x。但他們真的是這樣嗎？正如您可能希望的那樣，較好個選項顯然比第二個選項包含更多不必要的認知負擔。第二個選項您可以從左到右逐字閱讀并理解代碼的意圖。在前者中，您必須將眼睛和上下文從一段代碼切換到另一段代碼。同時，你必須記住每次都要過濾你頭腦中的值，并記住*條件。

當然，有些人可能會說他們不熟悉第二個示例中的語言結(jié)構(gòu)。這就是開發(fā)人員的經(jīng)驗發(fā)揮作用的地方。這是您必須“git gud”來了解可以應用什么、如何應用它，甚至是否將某些工具應用于解決方案的地方。但每一個這樣的構(gòu)造、每一個模式、每一個范式都與問題無關。它只是為了幫助您解決問題。

我并不是想說函數(shù)式代碼更好。或者說越短越好。是的，這些例子看起來沒什么大不了的。但它們確實表明了我的主要觀點——在較好種情況下，我們強迫開發(fā)人員校對僅與解決問題間接相關的代碼。按條件提前返還？這是一個實現(xiàn)細節(jié)，與要解決的問題無關。聲明一個帶有默認值的變量？再說一遍，這和我們的問題有什么關系呢？循環(huán)內(nèi)的條件？又一個細節(jié)。即使循環(huán)本身也只是一個細節(jié)。代碼中的此類細節(jié)越多，它的可讀性就越差（而且很可能會如此）。

現(xiàn)在，你們中的一些人可能會說，這一切都取決于范式、語言結(jié)構(gòu)或開發(fā)人員的經(jīng)驗，或者通常這就是編程的要點！但你混淆了兩件不同的事情：

• 固有的復雜性
• 附帶復雜性

什么復雜性？

我簡單引用一下：

固有的復雜性——相關軟件試圖使實際問題變得更簡單、更好的難度。

附帶的復雜性——關于軟件的任何困難但不一定是困難的事情

附帶復雜性是由庫、框架、語言、范例、開發(fā)人員偏好等引入的。固有復雜性是為了解決所選領域的基本問題而必須做出的權衡。一個好的工程師會減少附帶的復雜性并嘗試接受和處理固有的復雜性。

所以不，如果您可以輕松理解#ifdefs每 5 行嵌套的代碼，或者您非常擅長閱讀 ruby?? 元編程，并使用 eval 將類成員委托給抽象上下文 - 這并不意味著該代碼是可讀的?；蛘咭苍S是這樣。但較終只有你學會了閱讀一堆偶然的復雜性。而且，總的來說，這沒有什么問題——這樣的代碼數(shù)量驚人，能夠理解它總比不理解好。但解決方案的可讀性與你無關

那么這不是一個偏好問題嗎？

為什么不？畢竟，代碼對您個人來說是否可讀還取決于您的經(jīng)驗和偏好。

但您的偏好絕不會影響解決方案的復雜性和可讀性。例如，您需要使用分片實現(xiàn)緩存集群，并能夠基于跳躍一致哈希按大小和數(shù)量重新分片（這將導致項目重新分配）。所有這些都應該即時發(fā)生，停機。當然，還有緩存快照、正確的驅(qū)逐策略和高命中率！這個領域本身已經(jīng)夠復雜了，為什么還要增加更多的復雜性和問題，并稱之為別人的“技能問題”呢？老實說，這在某種程度上仍然是不可避免的。但只是在某種程度上。因為正確的解決方案之后的下一個目標是盡可能減少附帶的復雜性和不必要的細節(jié)。所以，請停止通過偏好來證明難以掌握的代碼（而不是復雜的代碼）。

這完全取決于解決方案的可讀性。