What Did You Mean by 'data2'? Writing Names That Actually Survive the Night

There's a specific kind of dread that hits when you open a file you wrote six months ago and see a variable called temp2. Not temp. temp2. Which means at some point there was a temp, it wasn't enough, and instead of reconsidering the approach, past-you just... added a number. No explanation. No comment. Just a silent acknowledgment that things had gotten out of hand.

This is the naming problem, and it's more universal than most developers want to admit. We spend enormous energy debating architecture patterns and arguing about tabs versus spaces, but the single thing that makes code readable day after day — the names we give things — often gets treated like an afterthought.

It shouldn't. Names are the primary interface between your code and every human brain that has to interact with it, including yours.

The Real Cost of Vague Identifiers

When a variable is named x, a function is called handleIt, or a class is labeled Manager, the reader has to do extra cognitive work before they can even begin understanding the logic. They have to reverse-engineer intent from context — scrolling up and down, checking call sites, tracing data flow — just to figure out what the dang thing is supposed to represent.

That's friction. And friction compounds.

On a team of three developers, each spending an extra five minutes per session deciphering unclear names adds up to hours of lost productivity per week. Multiply that across a codebase that's been accumulating vague identifiers for two years, and you're looking at a serious, invisible drag on your team's velocity. The worst part? It never shows up in a sprint retrospective because nobody can point to the exact moment it cost them time.

Poor naming also creates a subtler problem: it erodes trust in the codebase. When developers can't tell what something does by reading its name, they start adding defensive comments, writing extra tests just to feel safe, and eventually avoiding whole sections of code because they're too risky to touch. That's how you end up with the legendary "don't go near the billing module" warning passed down like folklore.

What Good Naming Actually Looks Like

Let's get concrete. Here are a few before-and-after comparisons that illustrate the difference intentional naming makes.

Before: let d = new Date();
After: let invoiceCreatedAt = new Date();

The first version forces you to look at how d is used to understand what date it represents. The second version tells you immediately — it's the timestamp for when an invoice was created. You can read the surrounding code without mentally pausing.

Before: function process(items) { ... }
After: function applyDiscountsToCartItems(items) { ... }

process is one of the most overloaded, meaningless words in software development. It tells you that something is happening. The revised version tells you what is happening and to what. That specificity is documentation you don't have to maintain separately.

Before: const flag = user.role === 'admin';
After: const isUserAdmin = user.role === 'admin';

Boolean variables deserve special attention. Prefixing them with is, has, can, or should signals their nature immediately and makes conditionals read like plain English. if (isUserAdmin) is just easier to parse than if (flag).

A Framework for Choosing Better Names

Rather than relying on instinct, it helps to have a repeatable mental process. Here's a lightweight framework you can apply whenever you're about to name something:

1. Name the concept, not the container.
A variable named array tells you the data structure. A variable named pendingOrderIds tells you the concept. Always favor the concept. The type system (or a quick hover in your IDE) can tell you it's an array.

2. Encode intent, not implementation.
If you rename a linked list to a hash map later, linkedListOfUsers becomes a lie. activeUsers remains accurate regardless of the underlying data structure. Name what the thing means, not how it's built.

3. Match the domain language.
If your business team calls something a "fulfillment window," your code should too. Using deliveryRange when the rest of the organization says "fulfillment window" creates a translation layer in every developer's head. Domain-aligned naming reduces the gap between the business and the codebase.

4. Ask: would a new teammate understand this in isolation?
Imagine dropping a new developer onto your team on their first day. If they can read the name without any surrounding context and get a reasonable sense of what it represents, you're in good shape. If they'd need to trace three files to make sense of it, it needs work.

5. Avoid noise words.
Words like data, info, manager, handler, and util rarely add meaning. UserDataManager is just a class that does something with users. Call it UserAccountService or UserProfileRepository — something that describes the actual responsibility.

Names as Living Documentation

One of the best arguments for investing in naming is that good names age better than comments. Comments lie. Not intentionally — but code changes, and comments often don't keep up. A function called calculateNetRevenue that has drifted into also handling tax adjustments is a problem, sure, but a comment that says "calculates net revenue" while the function secretly does three other things is actively misleading.

Names, on the other hand, are harder to ignore when they're wrong. A misnamed variable creates a visible inconsistency that someone will eventually notice and fix. A stale comment can persist for years because it looks like documentation.

This is why the Carving Code philosophy treats naming as a craft skill rather than a cosmetic choice. When you carve a piece of wood, the shape you give it determines how it functions and how long it lasts. Names work the same way. A well-chosen name gives a piece of code its shape — its identity — and that identity carries forward every time someone reads, extends, or debugs it.

When Renaming Is the Right Move

If you've inherited a codebase full of cryptic identifiers, you don't have to fix everything at once. Rename things opportunistically: when you're already touching a file, clean up the names you encounter. Most modern IDEs make project-wide renaming safe and fast, so the mechanical risk is low.

Prioritize the names that appear most frequently or live at the highest levels of abstraction. A vague module name causes more confusion than a vague local variable, because it shapes how developers think about the entire system.

And don't underestimate the value of a good naming discussion in a code review. Pushing back on an unclear name isn't nitpicking — it's an investment in every future reader of that code, including the author themselves.

The Name You Write Today Is a Message to Tomorrow

Every name you write is a small act of communication across time. The variable, function, or class you're naming today might be read hundreds of times over the next few years, by people under deadline pressure, debugging production issues, or trying to onboard quickly. What you call it is what they'll have to work with.

That's not pressure — it's purpose. Take the extra thirty seconds. Think about what the thing actually is, not just what it temporarily holds. Write the name that makes the code explain itself.

Future you will be grateful. And so will everyone else.