举个例子，想想食物。如果我告诉你，我昨天晚上出去吃了高品质的食物，你可能会将自己的定义映射到我的经验上。也许你会描述为高价格、甘蓝和有机松果。这还太低级了? 也许小土豆+香煎牛脊也是很昂贵的。但无论哪种方式，明确的要点是高价格和有机食物。那这意味着什么? 也许对你来说，高品质的膳食是一种便宜的熟食三明治，谁在乎其来自哪里呢? 当然，如果你在森林里迷路了快一周了，你可能会重新定义高品质的食物，即可食用就是高品质。
你可能会得有这种想法。你判定食物的方法是主观的，也是场景依赖的。同样的道理也适用于我们对待代码的方法。当我们谈论代码质量时，我们把自己的语境和主观性带到其中。但是，就像食物一样，我们也倾向于认为人其他人明白我们内心的定义。我们可以将这称为天真现实主义的人类认知偏见。
那么你会如何去解读代码质量，至少与他人达成一些共识呢?
代码质量：通过否定下定义
也许最简单的开始方式是从否定开始。毕竟，如果要说我们从 Software Engineering Stack Exchange 中学到些什么的话，我们知道了在该问题被作为“非建设性问题”关闭前，哪种构建代码质量的问题会激发数百个投票、大量的回答和诸多评论。我们也知道，人们可以投票选出代码质量的错误定义。
各个地域的人们似乎都认为质量差的代码引发后期阅读者的质疑。他们会在读过代码后高喊：“这是什么玩意?” 低质量的代码给我们带来困扰，就跟这个毁誉参半的卡通漫画一样。
我实际上认为这给之后的讨论开了个好头。 当你有质量差的代码时，它会使人困惑，难以理解。 因此，对它进行讨论似乎是理解代码质量的不错开始 —— 那人们会快速容易地理解它们。
当然，你可能会指出，任何代码都或多或少会混淆一些基本的软件知识。 所以也许我们应该考虑一下参考大多数相关技术软件开发人员的代码。
代码应专注于做该做的事
我们在迁移到简单直观的标准之前可以从反面设立一些探索点。一段高品质的代码，应该是普通开发者应该能够快速，轻松理解的代码。反之，则不能称之为高品质代码。
注意这会导致出现一种情况：一段极端聪明或者极具开创性的代码不能被冠以高品质。大体来说，我觉得这是可以的。如果你编写出了难以理解的算法，解决了一个独特的、有效的问题，也许代码质量评判不会给你最高的分数，你会备受打击。但你的贡献其实并不是这个函数本身的代码质量，而是这个函数解决了什么问题。
这也带来了关于代码质量的另一个重要特征。作为高质量的筹码，它应该为预期的目的服务。也就是说，高质量的代码没有缺陷、没有性能问题、没有安全漏洞，也没有其它与目的相悖的东西。草率的代码也可以达到目的(甚至可以完成得很好，尤其是在对某个问题产生创新解决方案的情况下)，而且你应该能理解代码中会充斥着缺陷。它们都不是高质量的代码。但是可理解的代码，其目的是为了不让你出局。
读起来像散文
在某些合适的筹码下，这个定义的门坎更高。假设你写的代码已经符合最小惊讶原则，而且它正确地做了该做的事情。现在你的代码在做正确的事情，也不会引起人们的反感。这很好，不过似乎我们还可以做得更好。
整洁代码的提倡者提供了一系列关于这个主题的格言警句。这些想法包括不创造惊喜，做想做的事，在代码中体现代码写作人的心意。但是我觉得 Grady Booch 的总结可能更清楚。
整洁的代码简单而直接。整洁的代码读起来就像在读很好的散文。
这就告诉你关于达成高质量代码(和干净的代码)的更有效的事项。编程语言倾向于使用大多数非程序员根本不会用的语法。它们将语义的奥秘推向极致。编程语言给你各种各样的机会形成官方文章。
所以，从某种意义上来说，高质量的代码不管那些。它掌握所有标点符号、符合语言特征的语义并把它们以“读起来像好散文”的方式呈现出来。不仅优雅，而且具有很高的质量。
良好的代码质量具有基本的商业意义
到目前为止，我已经提供了一系列探索方法，其中我将我对问题的看法制成表格。我确实认为这是编写高质量代码的重要组成部分。 但是，正如我刚才所说，这样做仅仅是我的主观观点。 所以你要当心。
我以一致性为基础，阐明了高质量的代码不会让人困惑和混淆，它会做你让它做的事，并将其意义清楚地传达给维护者。像我提到和引用的那些观点，我相信它们说的是对的。
我觉得很难用一个一般的标题将它们整合起来。 高质量代码是通过将总体的代码拥有成本降至最低来实现的。 这就是为什么快速理解，正确性和清晰度是如此重要。 高质量的代码不会过度增加变更的难度，不会有不断的故障排除和无休止的返工重写造成的资金的浪费。 恰恰相反，它会以极简主义的方式服务于其目的。
我觉得我们会就高质量代码达成共识。说实话，如果我们都做到这一点，我可能会感到失望。 但是，无论是否达成共识，我认为，考虑代码质量的问题会超越你自己原有的认知，并且会想在支付的业务层面，是什么影响了代码质量。
