较近经常提出什么是代码可读性（通常作为神秘 DX 的一部分）的问题。越来越多的人开始说可读性纯粹是一个偏好问题。我不能责怪他们。经过多年的发展，我们可能会认为我们已经完全有能力感知不同质量、范式和语言的不同代码。我们也可以习惯那些起初让我们觉得不舒服的工具。并得出结论：一切都取决于经验！嗯，是的，也不是。

这是一把双刃剑

佐丁较近表示：这种质量有两个目的——代码的可读性和可维护性如何，以及程序员的熟练程度如何

你知道，我对这个观点有些满意。它本可以就此打住，但后来 Tsodin 对程序员本身进行了更多的掩盖，并将一切都简化为广义的“git gud”。

这个说法的问题在于，我们有点含蓄地说——任何代码都是可读的，只是你没有足够的技能！老实说：并非所有代码本身都是可读的。

哦，但是你能定义什么是可读性吗？

您可能经常听到这样的问题：“您能定义可读性吗？不，不，不仅仅是可读性，还有代码可读性，这是完全不同的，你知道。»

事实上，根据定义，可读性分为多文字表现和文本的语言特征。但我们不是来评估字体或连字对代码可读性的贡献，对吗？

我们真正感兴趣的是代码的语言方面：

• 命名；
• 句法结构的复杂性；
• 抽象程度；
• ETC。

“是的，这些都是偏好。” 不，他们不是。因为代码和文本之间有一个重要的区别：与文本不同，代码有义务实现其意图。文本是否达到其目的实际上并不那么重要。例如，作者试图通过文本传达的想法或概念。如果他们不喜欢，那么，这只是一个糟糕的文本。它仍然在那里，文字是相关的，只是不善于表达思想。但代码必须解决预期的问题，否则它就是字面意义上的错误且不适用。不好≠错误。

所有这些可能使我们相信代码可读性实际上是一种复合现象：

• 它包括问题的正确解决方案；
• 它完整​​地描述了工作算法（即，它实际上并没有对我们的意图撒谎；）
• 并且这个解决方案的可读性较大程度地与问题本身成正比。
• 

代码可读性并不是你想象的那样

请注意我们如何从“代码可读性”切换到“解决方案可读性”？我相信这是表征可读性问题的主要特征：我们试图在没有上下文的情况下看待这个术语。当我们尝试判断代码的可读性时，许多人主要判断代码本身，而不是它试图解决的问题。这就是争论开始的地方：过程性代码比函数式代码更具可读性，声明性代码比命令性代码更清晰，继承与组合以及一堆其他流行语。

您的编码风格可能对您来说更具可读性，但这并不意味着它可以形成可读的解决方案。

现在，让我们看一下非常简单（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

愚蠢的例子，对吧？但什么样的代码更具可读性呢？你们中有些人会说两者都非常可读。但他们真的是这样吗？正如您可能希望的那样，较好个选项显然比第二个选项包含更多不必要的认知负担。第二个选项您可以从左到右逐字阅读并理解代码的意图。在前者中，您必须将眼睛和上下文从一段代码切换到另一段代码。同时，你必须记住每次都要过滤你头脑中的值，并记住*条件。

当然，有些人可能会说他们不熟悉第二个示例中的语言结构。这就是开发人员的经验发挥作用的地方。这是您必须“git gud”来了解可以应用什么、如何应用它，甚至是否将某些工具应用于解决方案的地方。但每一个这样的构造、每一个模式、每一个范式都与问题无关。它只是为了帮助您解决问题。

我并不是想说函数式代码更好。或者说越短越好。是的，这些例子看起来没什么大不了的。但它们确实表明了我的主要观点——在较好种情况下，我们强迫开发人员校对仅与解决问题间接相关的代码。按条件提前返还？这是一个实现细节，与要解决的问题无关。声明一个带有默认值的变量？再说一遍，这和我们的问题有什么关系呢？循环内的条件？又一个细节。即使循环本身也只是一个细节。代码中的此类细节越多，它的可读性就越差（而且很可能会如此）。

现在，你们中的一些人可能会说，这一切都取决于范式、语言结构或开发人员的经验，或者通常这就是编程的要点！但你混淆了两件不同的事情：

• 固有的复杂性
• 附带复杂性

什么复杂性？

我简单引用一下：

固有的复杂性——相关软件试图使实际问题变得更简单、更好的难度。

附带的复杂性——关于软件的任何困难但不一定是困难的事情

附带复杂性是由库、框架、语言、范例、开发人员偏好等引入的。固有复杂性是为了解决所选领域的基本问题而必须做出的权衡。一个好的工程师会减少附带的复杂性并尝试接受和处理固有的复杂性。

所以不，如果您可以轻松理解#ifdefs每 5 行嵌套的代码，或者您非常擅长阅读 ruby​​ 元编程，并使用 eval 将类成员委托给抽象上下文 - 这并不意味着该代码是可读的。或者也许是这样。但较终只有你学会了阅读一堆偶然的复杂性。而且，总的来说，这没有什么问题——这样的代码数量惊人，能够理解它总比不理解好。但解决方案的可读性与你无关

那么这不是一个偏好问题吗？

为什么不？毕竟，代码对您个人来说是否可读还取决于您的经验和偏好。

但您的偏好绝不会影响解决方案的复杂性和可读性。例如，您需要使用分片实现缓存集群，并能够基于跳跃一致哈希按大小和数量重新分片（这将导致项目重新分配）。所有这些都应该即时发生，停机。当然，还有缓存快照、正确的驱逐策略和高命中率！这个领域本身已经够复杂了，为什么还要增加更多的复杂性和问题，并称之为别人的“技能问题”呢？老实说，这在某种程度上仍然是不可避免的。但只是在某种程度上。因为正确的解决方案之后的下一个目标是尽可能减少附带的复杂性和不必要的细节。所以，请停止通过偏好来证明难以掌握的代码（而不是复杂的代码）。

这完全取决于解决方案的可读性。