Naming

The first rule of articles about naming in programming is that you must tell the joke. I’ll get it out of the way so we can all relax and it won’t sneak up on you later.

There are only 2 difficult things in programming. Cache invalidation, naming and off by one errors.

There, we’ve said it, its done.

Why is naming difficult?

Naming is difficult. Often really difficult, sometimes really jolly difficult.

Its a difficult thing to get right because it takes us out of the flow of coding, and forces us to be creative in a different way to the problem solving way we are used to.

When you a naming something, you must empathise with a hypothetical future-person, who is jumping into this piece of code for the first time (or the hundredth time), and concoct a name that will be obvious to them. The trickiness is we don’t know who they are, what context they’ll have, if they got much sleep last night, and if they have a sense of humour.

Strategem

Like Jesus, I have one golden rule that sums up all the others. But in fairness to Jesus, his golden rule is a little more broad. Mine deals in a specific aspect of being kind to one’s neighbours.

Name things for what they are FOR

This sounds basically obvious, but there is some nuance here, and that may be revealed by stating the negatives.

DO NOT Name things for what they DO

DO NOT Name things for what they ARE

An example

So say for instance we have a service that handles authentication, and we are looking to expose a boolean in our api that says that a user has signed in and has been issued an authentication token.

We have a few options here, we could expose hasToken: boolean or hasSignedIn: boolean or isAuthenticated: boolean.

But which is correct?

Which are wrong?

Why?

hasToken is certainly true, but its exposing unnecessary information, we don’t care of the method of authentication, tokens might be invalid or expired so having a token might not even logically map to being signed in. This is an example of naming things for what they ARE.

hasSignedIn is perhaps better, as its answering the question of what we want to know, but its implying a process that user has signed in. Especially if we consider that at the moment there may only be one way of becoming authenticated, by signing in, but in future there may be SSO sign ins, or other ways of authenticating. And then this is exposing unexpected and possibly incorrect information. This is an example of naming things for what they DO.

isAuthenticated is the correct name as it reveals the information that the user of our api wants to know. It leaves the api open for extension without needing to change its external surface. This is because it is named for what it i FOR.

Tactics

Well, you’ve seen a really simple example, and most things you’ll struggle to name will be potentially more difficult. So are there some tips and tricks you can use to help you on your way to consistently naming things well? Why, yes, there are, and good news for you, I’m going to tell you about them

Think about your audience

If you are exposing something to be named for a consumable API, you should consider what the user of that API is trying to understand. The Interface Segregation principle states that a user should not have to know anything about anything they do not use. This is true of programming interfaces in a literal sense, but is something we should consider in a mental sense, the names of our attributes and methods should not make a user have to think about anything other than what they want to use.

If you are naming an internal variable, you should give it the same amount of care as above. Consider the user of this variable as the next engineer to read the code, assume they know nothing but the general operating principle of the whole code, and therefore variables should be named to be as explicit and detailed as possible (while still being reasonably terse).

Don’t abbreviate words

For ease of guessability, don’t abbreviate words, a future user might not think to abbreviate a word in the same way and therefore abbreviations make everything less intutive to work with.

Prefix booleans with is or has or should

To make it easier for readers of code to guess the type of a variable, booleans should be prefixed with is or has or should. Conversely, non-booleans should never be prefixed with is or has or should.

Consider how you might ask a LLM to generate a name

Hey look, its a blog in 2025, it needs to mention LLMs and AIs otherwise its not in keeping with the zeitgeist.

If you think about what you would prompt your favourite AI with to name a function for you, if you make sure you phrase the question about the “what its for”, you’ll get a better answer.

And you don’t necessarily have to then ask an AI that question, you can pose the question for your own brain too.

For instance, say we have this function:

function nameThisFunction(token: string) {
  const tokenDetails = jwtDecode<{ "cognito:groups"?: string[] }>(token);

  if (
    tokenDetails["cognito:groups"] &&
    tokenDetails["cognito:groups"].includes("admin")
  ) {
    return "admin";
  }

  return "user";
}

We could prompt an AI:

“create a name for a function that gets the cognito group from a jwt token”

and it would return a suggestion like getCognitoGroupsFromJwt. Which is named for what it does, but it doesn’t tell us what its for.

Lets take a look contextually at what this function might be for, and we can see that it either returns “admin” or “user”. So clearly this function is about determining the user type, and the cognito groups and jwt tokens are merely implementation details.

So we can now prompt our AI with

“create a name for a function that determines if a user is an admin user or a normal user”

and the AI returns something like getUserRole, which is absolutely delicious.

Sometimes it can be useful to prompt an AI as names are really tricky, but other times simply thinking about how to prompt an AI will give you the insight to come up with the right name.

Conclusion

Naming is a bit tricky, and sometimes it can break our flow while we are working, which is annoying. But if we follow some simple conventions and try and name things for what they are FOR not what they do, we can make it a bit easier.

Now we’ve covered those tricky issues, you can look forward the 3 new articles I’m currently writing. One will cover cache invalidation, and the other off-by-one errors.