编程与软件工程typicalprogrammer.com
代码可读性到底指什么？
What does code readability mean?
2018 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章探讨「代码可读性」到底指什么：作者认为它并非代码的固有属性，而很大程度上取决于读者的经验、兴趣、耐心和好奇心——同一段代码对不同的人可读性不同。文中也讨论了我们常把「我不喜欢这种风格」误当成「这代码不可读」，并列举了代码让人读不下去的几种原因。
为什么经久不衰：它把一个被当作理所当然的工程概念拆开审视，触及编程中主观与客观、风格与复杂度之间的长期争论，因此多年来反复被翻出来讨论。
HN 评论精选
借用 Hickey 的 simple/easy 之分：简单是客观的（关注点不纠缠），容易才是主观的。
「好代码就是简单」这句话其实什么也没说……我们所谓的「简单」取决于经验、技能、兴趣、耐心和好奇心。我喜欢 Rich Hickey 的立场：「simple」是客观的（反义词 complex），而「easy」是主观的（反义词 hard）。Easy 依赖技能和兴趣，simple 不依赖。Simple 指的是关注点没有纠缠在一起，指代码无需把整个代码库装进脑子就能理解。比如纯函数，看一眼就懂，它是简单的；如果它修改或使用了全局变量，你就得去看所有碰过这个变量的地方，代码因此复杂得多。按这个定义，说代码应当尽可能简单完全正确——而写出简单的代码通常非常难。
virgilp查看英文原文
> “Good code is simple” doesn’t actually say anything. [...] What we call “simple” depends on our experience, skills, interest, patience, and curiosity. I like Rich Hickey's stance on this: "simple" is objective (antonym: "complex"), whereas "easy" is subjective (antonym: "hard"). Easy depends on skills, interest, patience, curiosity - but simple does not. Simple is about lack of intertwining of concerns. About writing code that can be understood without "bringing in" the entire codebase into your mind. Like, you can understand a pure function just by looking at it (it's simple). If it modifies or uses a global variable, now you have to look at all the places that "touch" that global variable, in order to understand what your function does; the code is thus much more complex. With that definition - it's absolutely correct to say that the code should be as simple as possible. And that writing simple code is typically very hard.
文学类比不成立：代码有可衡量的等价结果，文学没有。
作者反复把代码语言风格和文学语言风格作类比，我觉得这个类比毫无帮助。文学靠的是纸面文字与读者心智之间难以厘清的复杂互动，换一个词就可能彻底改变一段文字的效果，取决于词义、每个读者的联想、以及词的外观和读音。而且我们没有办法客观衡量文学的效果，没有测试能测出读完小说后我变得多有共情。代码通常有可衡量的结果：虽然「可读性」仍偏主观，但至少当结果相同时（数组排对了、金额算对了、像素渲染一致）我们可以说这两个版本的函数是等价的。所以改代码和改文章完全不同：《麦克白》的梗概永远无法在读者心中产生读原著的效果，但一个主观上更易读的函数可以被客观证明与原函数效果相同。
gabemart查看英文原文
The author consistently compares code language style to literature language style, but I don't think it's a helpful comparison at all. Literature operates by an intractably complex interaction between the words written on the page and the mind of the reader. Exchanging a single word for another may totally alter the effect of a passage, based on factors like the meaning of the word, the associations the word has for each reader, and the aesthetic appearance and sound of the word. Moreover, we have no objective way of measuring the effect of literature. We don't have a test that can measure how much more empathetic I become after reading a novel, or how much more I understand the human experience. Computer code typically has measurable outcomes. While "readability" may still be a relatively subjective measure, we can at least say "these two versions of this function are equivalent" if the outcome is the same - the array is sorted correctly, the transaction amount is calculated correctly, the graph is rendered with the same pixels. This means that editing computer code is nothing at all like editing literature. The cliff-notes version of Macbeth can never produce the same effect in the mind of the reader as reading Macbeth -- but a function that is subjectively easier to read can be shown objectively to produce the same effect as the original function.
可读性因人而异；很多「重构」其实是懒得读别人的代码，而读代码本应被更重视。
这是一篇发人深省、写得也好的文章，讲的是程序员在阅读和评判别人代码时的偏见。作者的观点是：代码可读性终究取决于观者。我逐渐认同这一看法，而且我觉得编程文化里很少有人这么说。我工作过的大多数地方都有一种以「持续改进」为名不停重构的文化，但仔细看，动机其实是对上一个开发者编程风格的鄙夷，以及（在我看来）一种对读代码的普遍厌恶。读代码大约比写代码难十倍：更费神、更不好玩、更难，而且不会让任何人刮目相看。你得比写它的人更懂这门语言，因为你不只要理解它为什么做了作者想做的事，还要理解它为什么做了作者没想做的事（也就是 bug）。但我的经验是，愿意去读懂已有代码，长期看能为团队省下更多时间和精力。
tboyd47查看英文原文
This is a thought-provoking and well-written blog post about programmer biases when it comes to reading, and judging, other people's code. The author is making the point that code readability is ultimately in the eye of the beholder. I've come to share the author's views, and I have to say I don't hear it said much in programming culture. At most places I've worked, there's this culture of constant refactoring under the guise of "continuous improvement," when really, if you look closely, it's really motivated out of disdain for the last developer's programming style, and in my opinion, a general aversion to reading code. Reading code is about 10x as hard as writing it. It takes more concentration, it's less fun, it's harder, and it doesn't impress anyone. You have to know the language better than the person who wrote it, because not only do you have to understand why the code does what they intended it to, but you also have to understand why the code does other things they didn't intend (a.k.a. bugs). But in my experience, you save your team a lot more time and energy in the long run by preferring to read and understand existing code.
可读性虽有主观成分，但好代码和坏代码人人都能分辨，不可能是纯主观的。
这让我想起《禅与摩托车维修艺术》里关于「质量」的讨论：全班发现没人能准确定义质量，但面对高水平和低水平的文字，人人都能分辨。正如作者意识到的，没有人认为 Knuth 的《计算机程序设计艺术》写得差，尽管它很难读——优雅是显而易见的，即便算法难以理解。反过来说，我见过求职者写的 FizzBuzz，我费半天劲才看明白。我常常看到同一个问题的不同实现代码量差十倍，虽然有些边缘情况下更短的代码会变得费解，但总体上团队里每个开发者都能指出哪个更好读。我不反对可读性讨论中存在主观成分，但认为可读性纯属主观、只关乎风格差异，这很荒谬。而且我根本不信作者真的这么认为：他想说明主观性，这没问题，但不知为何选了这种夸张的标题党写法。
DavidWoof查看英文原文
This reminds me of the discussion of "quality" in Zen and the Art of Motorcycle Maintenance, where the class finds that while nobody can exactly define quality, when confronted with high and low quality writing everybody could recognize which was which. As OP realizes, nobody thinks Knuth's ACP is poorly written even though it's hard. The elegance is obvious, even if the algorithm is hard to understand. On the opposite end, I've come across FizzBuzz implementations from job candidates that I've struggled to follow. I've often seen a 10-1 difference in code sizes for different implementations of the same problem, and while there's edge cases where smaller code can start to become confusing, generally every dev on the team recognizes which of the two is more readable. I have no problem with the idea that there can be subjectivity in discussions of readability. But the idea that readability is purely subjective, or only has to do with differing styles is ridiculous. In fact, I don't believe for a second that OP really believes this. He wants to make a point about subjectivity, which is fine, but for some reason has chosen to write it in this exaggerated clickbait style.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选