> When we say that some code “is unreadable” we actually mean one or more of: > 1. I can’t read the code because I don’t have sufficient experience or exper

> When we say that some code “is unreadable” we actually mean one or more of: > 1. I can’t read the code because I don’t have sufficient experience or expertise (with the language or domain). > 2. I haven’t spent enough time trying to read and understand the code (“it’s not obvious” or “it’s not intuitive”). > 3. I don’t have much interest in understanding this code, I prefer to rewrite it in my own style. > 4. The code offends my sense of aesthetics; I would write it differently. > 5. The original programmer didn’t know how to write code. > 6. The code appears to violate some principles or patterns I believe in. The rest of the article mainly deals with 1-4 here, and only selectively tackles 6 as a "performative" repeat of 4. It does mention vaguely toward the end that there may be some objective sense of readability, but doesn't go into any technical analysis. Which is a shame as I don't think it's that complex. A few sibling commenters have alluded to this using various terms: ultimately I think objective code readability is about context and locality. Consider a static analysis security tool that produces a control flow analysis tree: often a long tree is a very good sign of bad readability (in practice a long tree can be caused by many things: excessive boilerplate, frequent variable mutation or reassignment, etc.) These same tools often fall down analysing control flow of applications with weird state patterns: global state, "magic" model loading, etc. Things that further hamper a reader's ability to hold a complete picture of any given file they're reading in their head at once. I think this is interesting because not only is it a fairly simple idea to reason about (context & locality) but it's even potentially automatable as a metric.