FORWARD THINKING

Feb 26, 2025

Stop Naming Things Like a Sleep-Deprived Monkey

Design

Dev

3D

Daniel Nice

"There are only two hard things in Computer Science: cache invalidation and naming things."

— Phil Karlton

Forward Flash

Well, it has been everything I can do to make time to get posts like this written and out, so I have not made the progress I wanted up to this point with our app. Hopefully, this will change soon.

5-Minutes Forward

  • Look Around Your Files
    Take 5 minutes to scan your latest project. Find at least three poorly named variables, functions, components, whatever, and rename them using the principles from this post. A small fix today saves lots of frustration later.

  • Rename Before You Explain
    The next time you find yourself about to explain what a name means in a comment, commit message, or Slack thread—stop and rename it instead. If a name needs extra explanation, it’s probably not doing its job. Take 5 minutes to make it clearer so the next person (including the future you) doesn’t need the extra context.

Want more? Make this a habit—naming things well isn’t just a one-time cleanup; it’s a mindset. Decide what syntax format and consistency work for you and stick with it.

Feb 26, 2025

Stop Naming Things Like a Sleep-Deprived Monkey

Daniel Nice

"There are only two hard things in Computer Science: cache invalidation and naming things."

— Phil Karlton

0:00/1:34

Forward Flash

Well, it has been everything I can do to make time to get posts like this written and out, so I have not made the progress I wanted up to this point with our app. Hopefully, this will change soon.

View All Posts

5-Minutes Forward

  • Look Around Your Files
    Take 5 minutes to scan your latest project. Find at least three poorly named variables, functions, components, whatever, and rename them using the principles from this post. A small fix today saves lots of frustration later.

  • Rename Before You Explain
    The next time you find yourself about to explain what a name means in a comment, commit message, or Slack thread—stop and rename it instead. If a name needs extra explanation, it’s probably not doing its job. Take 5 minutes to make it clearer so the next person (including the future you) doesn’t need the extra context.

Want more? Make this a habit—naming things well isn’t just a one-time cleanup; it’s a mindset. Decide what syntax format and consistency work for you and stick with it.

Question

What Should I Name This?

My Perspective

I believe the quote by Phil Karlton is indeed true. Naming things whether you are in a design file or in a codebase is one of the most challenging things people have to do. Its not that it is hard to type a name. What is hard is giving a good name that actually makes sense.

Naming is one of those deceptively simple problems—until you’re staring at a variable, function, or layer name, trying to decide between dataListFinalFinal_v2 or Rectangle 57. Poor names don’t just make code unreadable; they also turn design files into scavenger hunts.

Here’s how to name things like you actually care about your teammates, as well as your future self.

1. Make Names Tell the Story

If you need a comment, a Slack message, or a whiteboard session to explain what something means, it’s a bad name. Your code and designs should be self-documenting.

  • Bad: d = 100

  • Good: daysUntilExpiration = 100

This applies just as much to Figma files. Naming a frame “Big Box” means nothing, but “Product Card Container” tells you what it is and how it’s used.

2. Use the Language of the Problem

The best names match how real people talk about the thing you’re building.

  • Bad: data

  • Good: customerOrderList

Would a non-developer or non-designer understand what “Primary CTA” is? Probably. Would they know what “Big Red Thing” means? Probably not.

3. Be Unambiguous (Your Future Self Will Thank You)

A name should have only one possible meaning.

  • Bad: result (Result of what?)

  • Good: paymentVerificationStatus

In a design file, “Modal” is vague if there are six different modals. “Delete Confirmation Modal” is crystal clear.

4. Pick a System and Stick With It

If your booleans use isSomething, don’t switch to hasSomething halfway through. If your colors are named primaryText, don’t suddenly switch to textMain.

  • Consistent: isLoading, isComplete, isError

  • Inconsistent: isLoading, completeState, errorHappened

Designers: If your spacing tokens start as spacingSmall, don’t suddenly switch to space_Sm. Pick one style and commit.

5. Readability First

If a name feels awkward to say out loud, it’s probably a bad name.

  • Bad: isDataProcessed

  • Good: hasProcessedData

For designers, this means naming things based on purpose, not shape. “Card Background” is useful; “Blue Box” is a guessing game.

6. Match Names to Their Purpose

  • Use nouns for variables, classes, objects: customerProfile

  • Use verbs for functions: fetchUserData()

  • Booleans should be questions: hasPermission, not permissionStatus


  • Bad: publish (Is it a verb? A noun? Who knows.)

  • Good: publishedArticle

For Figma layers, “Bell” is useless. “NotificationIcon” is not and works whether you decide to change the icon later.

7. Stop Abbreviating

There’s no reason to abbreviate things anymore. We’re not coding on typewriters.

  • Bad: dd

  • Good: deliveryDate

And please, stop naming text styles “Hdr Lg”—just call it HeadingLarge.

8. Cut the Noise

Names should be as short as possible, but no shorter. If a word doesn’t add meaning, drop it.

  • Bad: userDataValue

  • Good: userProfile

Designers, you don’t need “Box” in the name if it’s already a box. “Button Container Box” is just “Button Wrapper.”

9. Don’t Be Misleading

If a name could mean two things, it’s a bad name.

  • Bad: userKey (Is it an API key? A database key?)

  • Good: userAuthToken

In Figma: A frame called “Modal” is too generic. “Delete Confirmation Modal” actually tells you what it is.

Final Thought: Naming is an Act of Kindness

Your names should make sense at a glance. Every good name reduces mental effort, making your code and designs easier to read, maintain, and extend.

And this isn’t just about variables or layer names. Anything with a name, whether it be page names, navigation labels, design tokens, and even commit messages all benefit from these same principles. When you name something well, you’re making it easier for the next person (which is probably you) to understand, use, and build upon it.

So next time you’re stuck, don’t settle for “data” or “Rectangle 57.”

Take a second, and ask yourself:

If all I had was the text from this name would I have an idea of what it is?