An opinionated (and mainly correct) guide to naming
The article presents a guide to naming conventions in software development, emphasizing clarity and consistency in naming variables, functions, and classes to improve code readability and maintainability. It offers practical advice on choosing descriptive names, avoiding abbreviations, and following established patterns within a codebase.
Background
- Adam Tornhill is a Swedish developer and author known for his work in software archaeology and code analysis (tools like CodeScene and books like *Your Code as a Crime Scene*).
- This essay argues that good naming in code is not subjective: names should follow a consistent, principle-based system tied to psychology and how humans read and recall identifiers.
- Key principles: names should be pronounceable (our brains process speech faster than visual symbols), based on a single abstraction level (no mixing low-level implementation details with high-level meaning), and follow the structure most natural to how we think (e.g., *The*Context*Name* pattern rather than *Context*Name*The*).
- Tornhill criticises common naming fashions like the "Clean Code" school (which over-emphasises short functions at the cost of naming clarity) and argues that acronyms and abbreviations harm comprehensibility far more than long names.
- The post is a reaction to decades of cargo-culted naming advice in software engineering, and offers a measurable, research-grounded alternative based on cognitive load theory.