Do you use clear and meaningful names when coding?
In the early days of coding, we had to store more information in our heads than in our computers, leading to all sorts of creative abbreviations and clever shortcuts. But today, storage and readability are no longer limitations—our computers can handle verbose names better than our brains can handle cryptic codes. Clinging to those old practices can hurt your code’s readability and make life harder for your team. Mental gymnastics waste time and money!
Names should always describe at first glance what something represents.
Video: Naming Conventions | Jeoffrey Fischer (5 min)
⚠️ Avoid mental encoding
Keep names obvious. It’s easy to invent codes to keep names short, like cstmrMgr
to represent a "customer manager" - and you might feel clever doing it. But this kind of shorthand requires other developers (or your future self) to mentally decode each abbreviation. There’s no good reason not to simply call it CustomerManager
(although there are reasons to avoid "manager" as a name - see rule on avoiding generic names like “manager,” “processor,” “data,” or “info”).
Be verbose
Today, we have the luxury of not worrying about character limits. While you shouldn’t use full sentences for a class or method name, there’s no reason to squeeze names into cryptic codes (testing can be an exception, see naming conventions for tests and test projects).
Full, meaningful words make your code readable and maintainable.
Scenario - Creating a game with user accounts and multiplayer
Say you are to create a variable to represent the player health...
Using Nrg
(variable short for "energy") is easy to write, but confusing to know what it means.
Bad example - Being clever for you can cause confusion to others. They might misinterpret "energy" as something else, like power or ammo. Then if you add enemies, would you name their energy variable nmeNrg
?
Using PlayerHealth
clearly describes the specific kind of "energy" (health) and who it belongs to (the player)
Good example - Instantly understandable to anyone reading the code
Now let’s say you’re working on an invitation and activation feature. You need a variable to store the validity period for an invitation - the live time...
Using itrDays
(shorthand for "invitation-time-remaining in days")
Bad example - Others will have fun deciphering this one
Using InvitationTimeRemainingInDays
requires no explanation!
Good example - Leaves no room for misinterpretation and makes the purpose obvious
What if you need to create some classes for validation...
Using UserValidator
as a class responsible for validating a user
Bad example - Validating what exactly? Login credentials? Profile information? Something else?
Using UserValidationHandler
indicates it’s an engine responsible for executing multiple rules to handle user-related validation.
Using UserNameLengthValidator
is for a specific aspect of a user - the length of a username.
Using UserEmailFormatValidator
to ensure email contains "@" and a domain.
Good example - The definition of the classes is in their names