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

We open source.Loving SSW Rules? Star us on GitHub. Star
Stand by... we're migrating this site to TinaCMS