Stop Making Devs Cry: The Art of Naming Things

The Problem Nobody Talks About

There are only two hard things in Computer Science: cache invalidation and naming things. But here's what they don't tell you—naming things is actually harder. At least cache invalidation has a technical solution. Bad naming? That's a special kind of torture that compounds every single day.

Every developer has experienced it: inheriting code where variables are named x, data, temp, or my personal favorite, bullshit. You spend three hours tracing through logic that could have been explained in three seconds with a decent name. That's not just inefficient—that's cruel.

Why Names Matter More Than You Think

Variables are documentation. They're the first thing another developer (or future you) reads. A good variable name answers the question: "What does this represent?" before anyone has to dig into the code.

When you name something poorly, you're not just being lazy. You're creating a tax on every person who reads that code. You're saying, "Figure it out yourself." And that's how devs cry.

---

The Hook: A Real Story

Imagine this scenario:

// What does this do?
const d = new Date();
const x = d.getTime();
const y = x - 86400000;
const z = new Date(y);

Now imagine this:

// What does this do?
const now = new Date();
const nowInMilliseconds = now.getTime();
const oneDayInMilliseconds = 86400000;
const yesterdayInMilliseconds = nowInMilliseconds - oneDayInMilliseconds;
const yesterday = new Date(yesterdayInMilliseconds);

The second one tells a story. You don't need to be a date expert to understand it. The variable names explain the intent.

---

The Story: Why Devs Actually Cry

Let me tell you about Sarah. Sarah inherited a codebase with 50,000 lines of code. The variables were named: a, b, temp, data, result, val, obj, arr.

She spent two weeks just trying to understand what each variable represented. She had to trace execution paths, add console.logs, and basically reverse-engineer the original developer's thinking.

When she finally asked the original developer what temp was supposed to do, he said: "I don't remember. It's been three years."

That's when Sarah cried. Not because the code was hard. But because it was unnecessarily hard.

---

The Code: Patterns That Work

Pattern 1: Boolean Variables Should Ask Questions

// ❌ Bad
const open = true;
const ready = false;
const active = true;

// ✅ Good
const isUserLoggedIn = true;
const hasLoadedInitialData = false;
const isComponentVisible = true;

Booleans should read like yes/no questions. Prefix with is, has, should, can, will.

Pattern 2: Collections Should Be Plural

// ❌ Bad
const user = [];
const item = getUserItems();

// ✅ Good
const users = [];
const userItems = getUserItems();

When you see users, your brain immediately knows it's multiple. No guessing.

Pattern 3: Functions Should Describe Actions

// ❌ Bad
const process = (data) => { /* ... */ };
const handle = (event) => { /* ... */ };
const do_thing = (x) => { /* ... */ };

// ✅ Good
const calculateUserTotalSpent = (userData) => { /* ... */ };
const handleFormSubmission = (event) => { /* ... */ };
const validateEmailFormat = (email) => { /* ... */ };

Functions should be verbs. They do something. The name should tell you what.

Pattern 4: Magic Numbers Get Named

// ❌ Bad
if (user.age > 18 && user.credits > 100) {
  const discount = price * 0.15;
}

// ✅ Good
const LEGAL_ADULT_AGE = 18;
const MINIMUM_CREDITS_FOR_DISCOUNT = 100;
const PREMIUM_DISCOUNT_PERCENTAGE = 0.15;

if (user.age > LEGAL_ADULT_AGE && user.credits > MINIMUM_CREDITS_FOR_DISCOUNT) {
  const discountedPrice = price * PREMIUM_DISCOUNT_PERCENTAGE;
}

Magic numbers are mysterious. Named constants are clear.

Pattern 5: Context Matters

// ❌ Bad - too generic
const data = fetchFromAPI();
const result = processData(data);

// ✅ Good - specific to domain
const userProfiles = fetchUserProfilesFromAPI();
const enrichedUserProfiles = addComputedFieldsToProfiles(userProfiles);

The more specific your name, the less context someone needs to understand it.

---

Real-World Example: Before & After

Before (The Nightmare)

const u = [];
const p = {};
const t = 0;
const s = false;

const f = (d) => {
  d.forEach((x) => {
    if (x.a > 18) {
      const c = x.b * 0.9;
      p[x.id] = c;
      t += c;
      s = true;
    }
  });
  return { p, t, s };
};

What does this do? No idea. Let's trace it... maybe it's calculating discounts? Or taxes? Who knows.

After (The Dream)

const eligibleUsers = [];
const discountsByUserId = {};
const totalDiscountAmount = 0;
const hasAppliedAnyDiscount = false;

const calculateEligibleUserDiscounts = (users) => {
  users.forEach((user) => {
    if (user.age > ADULT_AGE_THRESHOLD) {
      const userDiscount = user.purchaseAmount * SENIOR_DISCOUNT_RATE;
      discountsByUserId[user.id] = userDiscount;
      totalDiscountAmount += userDiscount;
      hasAppliedAnyDiscount = true;
    }
  });
  return { discountsByUserId, totalDiscountAmount, hasAppliedAnyDiscount };
};

Now you understand it immediately. No detective work required.

---

Tips to Stop Making Devs Cry

Tip 1: Use Full Words

Don't abbreviate unless it's a universally known acronym (like id, url, api). usr is not better than user. It's just shorter and meaner.

Tip 2: Avoid Single Letters (Except Loops)

i, j, k in loops? Fine. x for a user object? Unforgivable.

Tip 3: Be Consistent

If you call it userData in one place, don't call it userInfo in another. Pick one and stick with it.

Tip 4: Read It Out Loud

If you can't read your variable name out loud without feeling silly, it's probably bad.

"The value of x" → Feels bad. "The value of userEmailAddress" → Feels right.

Tip 5: Future-Proof Your Names

Name things for what they are, not what they currently do. If tempList becomes permanent, you've lied in your code.

Tip 6: Use Domain Language

If you're building a payment system, use terms like transaction, invoice, refund—not thing, item, stuff.

Tip 7: Length is Not a Crime

Yes, userAuthenticationTokenExpirationTimestampInMilliseconds is long. But it's clear. Clarity beats brevity every single time.

---

The Empathy Angle

Here's the thing: naming is an act of empathy. When you name something well, you're saying:

"I respect the next person who reads this code. I respect future me. I'm going to make this easy for you."

When you name something poorly, you're saying:

"Figure it out yourself. I couldn't be bothered."

And that's why devs cry.

---

Final Thought

The best code isn't the cleverest code. It's the code that explains itself. And that starts with names.

So next time you're about to name a variable temp or data, stop. Take five seconds. Ask yourself: "What does this actually represent?" Then name it that.

Your future self will thank you. And more importantly, you won't make other devs cry.

Stop making devs cry. Name things well.