"There are only two hard things in computer science: cache invalidation and naming things." It's a joke, and it's also an underrated engineering priority. Researchers have actually measured how much names matter to comprehension, and the answer is: more than most teams treat them. Given that engineers spend most of their time reading code rather than writing it, names are the interface to your codebase.
Key Takeaways
- In a study of 100+ programmers across 12 functions, full-word identifiers produced the best comprehension, clearly ahead of single letters, though often statistically tied with abbreviations (Lawrie, Morrell, Feild & Binkley).
- When code is uncommented, comprehension depends almost entirely on identifier names (the research).
- Improving names is often a better investment than adding comments (the research).
- Names are the cheapest documentation you'll ever write, and the only kind that can't go stale silently.
What the Research Found
Dawn Lawrie, Christopher Morrell, Henry Feild, and Dave Binkley ran a study that's refreshingly direct (What's in a Name? A Study of Identifiers). They took twelve functions and produced three versions of each, differing only in identifier style: single letters, abbreviations, and full words. Then they asked over a hundred programmers to describe what each function did.
Full words came out on top, and single letters came out clearly worst. The nuance the researchers are careful about, and that most summaries drop, is the middle: in many cases there was no statistical difference between full words and abbreviations (effective identifier names). So the strong, defensible finding is that meaningful names beat cryptic ones, with well-chosen abbreviations often holding their own against full words. The researchers also made a point worth sitting with: readers of code have two main sources of domain information, the names and the comments, and when a function has no comments, comprehension rests almost entirely on the identifiers. Their practical conclusion was that spending time on meaningful names may be a better investment than writing comments, and that it reduces the work of later maintenance.
| Identifier style | Comprehension |
|---|---|
| Single letters | Clearly worst |
| Abbreviations | Often statistically tied with full words |
| Full words | Best overall |
Why Names Beat Comments
Comments and names both carry meaning, and they age very differently. A comment can drift out of sync with the code silently: someone changes the logic, forgets the comment, and now the comment actively lies. A name lives in the code, so changing behavior tends to force a confrontation with the name. Names are also read every single time, while comments are skimmed or skipped.
This is why "self-documenting code" is more than a slogan. Given that engineers spend the majority of their time reading and understanding existing code, as the legacy-code research shows, the names are the primary interface. A well-named function saves a small amount of time on every future read, multiplied across everyone who ever touches it.
A Concrete Version
An engineer opens a function called "proc(d, f)" with no comments. To understand it, they have to read the whole body, then trace the callers, then guess. Fifteen minutes gone. The same function named "applyLateFeeToInvoice(invoice, feeSchedule)" is understood in three seconds, from the signature alone, without reading the body at all. The code is identical. The difference is entirely in what the author spent thirty seconds naming, and it repays that thirty seconds every time anyone reads it for the next five years.
The Honest Counterpoint
Long names are not automatically better, and the research finding "full words beat abbreviations" is not a mandate for "theCustomerAccountBalanceCalculationServiceFactory". Excessive length hurts readability too, and some abbreviations are so standard in a domain that spelling them out adds noise rather than clarity (id, url, http). Short names are also perfectly fine in tight scopes, where a loop counter named i in three lines carries no ambiguity. The finding is about meaningfulness at the scale where it matters, and the goal is a name that tells the reader what they need without making them read the body.
What This Means for Teams
Naming is one of the cheapest quality levers available and one of the most reliable signals of engineering maturity. Reviewing names in code review costs nothing and compounds across every future read, especially on distributed teams where you can't just ask the author what "proc" does. It's the same economics as documentation with better durability, and it directly reduces the comprehension tax that dominates work in existing systems. See available engineers.
Frequently Asked Questions
Do identifier names really affect comprehension?
Yes. A study of over 100 programmers across twelve functions found full-word identifiers gave the best comprehension and single letters the worst, though full words and abbreviations were often statistically indistinguishable.
Are good names better than comments?
Often. The research suggests improving identifier names can be a better investment than adding comments, partly because comments drift out of sync silently while names live in the code and get read every time.
Should every name be a full word?
No. Excessively long names hurt readability, standard domain abbreviations (id, url, http) are fine, and short names work in tight scopes. Aim for meaningfulness where it matters rather than maximum length.
Why does naming matter more on distributed teams?
Because you can't tap the author on the shoulder to ask what something does. The name has to carry the meaning across time zones and after the author has left.
The Bottom Line
Names are the interface to your codebase, and the research backs what good engineers already feel: meaningful identifiers comprehend far better than cryptic ones, and when code lacks comments they carry nearly all the meaning. Spend the thirty seconds. It repays itself on every future read, by everyone, forever.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
