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

這是一把雙刃劍

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

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

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

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

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

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

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

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

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

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

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

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

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

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

現(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。但他們真的是這樣嗎？正如您可能希望的那樣，較好個選項顯然比第二個選項包含更多不必要的認(rèn)知負(fù)擔(dān)。第二個選項您可以從左到右逐字閱讀并理解代碼的意圖。在前者中，您必須將眼睛和上下文從一段代碼切換到另一段代碼。同時，你必須記住每次都要過濾你頭腦中的值，并記住*條件。

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

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

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

• 固有的復(fù)雜性
• 附帶復(fù)雜性

什么復(fù)雜性？

我簡單引用一下：

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

附帶的復(fù)雜性——關(guān)于軟件的任何困難但不一定是困難的事情

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

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

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

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

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

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