# Naming: Stop Making Devs Cry

# 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:

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

Now imagine this:

```javascript
// 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

```javascript
// ❌ 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

```javascript
// ❌ 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

```javascript
// ❌ 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

```javascript
// ❌ 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

```javascript
// ❌ 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)

```javascript
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)

```javascript
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.**