10. Use One Name For One Thing

It sounds so logical: don't use the same name for different things in your project.

Yet I still encounter it regularly. And sooner or later, it leads to confusion, bugs, and frustration.

It's also wise to avoid names that can have multiple meanings by themselves. This helps you prevent misunderstandings before they even arise.

💡 Good names make good software.

Names are the bridge between code and people. If you build that bridge poorly, you'll eventually fall off.

Agree on naming conventions

Discuss as a team which terms you'll use and preferably document them in a project dictionary or glossary.

This doesn't have to be complicated — even a simple list in your repository often suffices.

Share this list with everyone involved in the project: developers, testers, designers, and possibly even stakeholders.

The earlier you align on this, the more technical debt you'll avoid.

Ideally, you should do this before you start coding. Renaming things later often means searching everywhere, updating everywhere, and risking errors everywhere.

A huge waste of time and energy.

Real-world example: the chaos of "date"

I once worked on a dating website where the word "date" was used for almost everything:

• A day or time
• A meeting with someone
• The person you are meeting
• The act of meeting someone

You would end up with sentences like:

“I will date my date on a date on that date.”

How confusing do you want it to get?

During development, it quickly became clear that this wasn't workable.

We decided that "date" would only refer to a day or time from then on.

For all other meanings, we chose alternatives like appointment, match, and meeting.

The code instantly became much more understandable.

Sometimes you need to deviate from client jargon

Another example: I once worked on a project involving the management of buildings.

The client consistently used the word "properties" to refer to buildings.

This made sense from their perspective, but in our React project, it caused major confusion — since "properties" (or props) already have a very specific meaning in React components.

To keep the code logical and readable, we decided to use the term "buildings" instead of "properties" in our codebase.

Of course, we documented this decision in the project dictionary so everyone was aware that "buildings" referred to what the client called "properties".

No confusion, no mistakes.

Sometimes you have to consciously deviate from client jargon to maintain technical clarity.

What you can do today

• Check if your project already has a glossary. If not, create one.
• Avoid generic or ambiguous words like data, info, item, value, date, user — unless you define them very clearly.
• Choose names that describe what something is, not what it happens to do in a certain context.
• Don't be afraid to refactor when you realize a name is causing confusion.

Good naming not only leads to better code but also to better communication within your team.

One name for one thing. Always.

Are you looking for someone who not only writes code but also brings structure, clarity, and stronger development teams?

As an interim Frontend Lead, I help organizations deliver better projects, faster and more successfully.

Feel free to send me a message! 🚀