The reliable naming approach serving me very well daily for 6+ years.
This is a well‑known quote in the SWE world, originally said by an engineer at Netscape over 20 years ago: “There are only two hard things in Computer Science: cache invalidation and naming things.” :)
So, the issue is, to put it mildly, nothing new. I read a recent article about a naming approach that felt to me mechanical and ineffective, likely based on "not invented here syndrome". And I decided to share my naming approach that is based on a combination of the long know ideas and practices that is really effective.
Note, that I only use it for OOAD and OOP in complex business domain areas. I am not sure if it works for functional programming or the other SWE areas like system programming etc.
The most important basis and a tool for an effective naming strategy for code identifiers was outlined in Eric Evans’s DDD book back in 2003: the Ubiquitous Language. This is essentially the foundation of good naming — it’s about using domain‑specific terms that the engineer standardises into a unique vocabulary.
With names built this way, the functional purpose of a variable, field, method, or class becomes immediately clear in domain terms. For example, take the object UploadedFileStreamValidation. Essentially, anyone reading the code is now reading it in the language of the domain.
Once we see such a name, we instantly understand the object’s responsibilities. Next, we need to determine the object’s place within a formal hierarchy of responsibilities — a hierarchy that’s actually quite universal across many domains.
And here, DDD comes in handy again. It already defines a set of object archetypes that clearly delimit their formal responsibilities. There aren’t that many of them: Value Object, Entity, Aggregate, Domain Service, Application Service, Repository, Factory, and a few others.
Add one of these archetypes to our identifier, and we get UploadedFileStreamValidationService. Now it’s clear where this object fits in the system, what it’s responsible for, and how it relates to other objects. This, really, is the very effective approach.
Now, a few simple conventions:
- Interfaces always start with I.
- Types start with T.
- Enums start with E.
- Abbreviations in are always in CAPS
- Class names are always in PascalCase.
- Variable and parameter names are always in camelCase.
- Object properties and database fields are always in snake_case.
- Constants are always in ALL_CAPS snake_case.
Add your own conventions when feels useful.
Applying the approach consistently multiplies readability and comprehension (!) for a new or returning reader. The code base written this way is a story about meanings, relations, intentions and outcomes that are the core elements to support the correct engineering decision making.
Using this kind of naming approach, you can build very large systems.
I’d be happy to discuss this further if anyone’s interested.