There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors. That’s right—three problems, and I meant that.

Let’s talk about naming, because I recently spent 45 minutes trying to name a boolean that checks whether a user, who was invited by a partner between June and October 2023, verified their email using an OTP (not SMS, unless it’s fallback), and didn’t use SSO… all for a feature flag that might be deprecated by next sprint.

I called it maybeQualifiedUserProbably.

And I slept like a baby—woke up every 2 hours and cried.

⸻

Naming Variables is Just Therapy You Don’t Pay For

Let’s look at how this usually goes:

let a = getStuff();
let b = processStuff(a);
let c = finalizeStuff(b);

Congratulations, you’ve written a microservice that sounds like a toddler describing their day.

So you try to improve it:

let userData = getUserDataFromThirdPartyIfNotSSO();
let processedUser = validateUserWithOnboardingStatus(userData);
let finalCheck = evaluateBusinessLogicThatNoOneUnderstands(processedUser);

Now you’ve got something! Something long, slightly unhinged, and still utterly unhelpful when it throws a null pointer at runtime.

⸻

The 7 Stages of Naming a Boolean

  1. flag
  2. isFlag
  3. shouldEnable
  4. shouldEnableFeature
  5. shouldEnableNewFeature
  6. shouldEnableNewFeatureIfAdmin
  7. shouldEnableNewFeatureIfAdminAndNotSSOAndNotLegacyUser
  8. 🫠

Yes, that’s 8 stages. Naming booleans breaks reality.

⸻

And Then There’s utils.js

Ah yes, the sacred dumping ground. Where variables go to die and functions go to lose all meaning.

Inside utils.js, you’ll find:

export function getDataStuffFinal(obj) { ... }
export function doThingWithParam(x) { ... }
export const val = true;

Good luck debugging that in production. It’s like trying to read hieroglyphs from a moving train.

⸻

How to Actually Name Things Without Crying

  • Use real nouns: userList > data
  • Be specific: emailVerified > isGood
  • Drop the temp, final, new garbage unless you’re naming a boy band
  • Don’t fear long names if they make things clear
  • Avoid foo, bar, baz unless you’re testing or trapped in a 1970s programming textbook

Bonus tip: if your variable name looks like a StackOverflow question title, you’ve gone too far.

⸻

Remember: we’re not writing Shakespeare, but we are trying to make code that won’t trigger PTSD when someone opens it six months from now. Including you.

So the next time you’re naming a variable, take a breath. Ask yourself: would I understand this name after three coffees and zero context?

If yes: ship it.
If no: rename it.
If you still can’t decide: maybeDoTheThingEventuallyIfNeeded.

⸻

If this hit a little too close to home, you’re not alone. We’ve all got a finalFix_REALLY_FINAL_final3.js somewhere.

Now go forth. Name things like a legend. Or at least like someone who has touched grass once.