Tips on naming boolean variables - Cleaner Code

Originally posted at michaelzanggl.com. Subscribe to my newsletter to never miss out on new content.

There is a convention to prefix boolean variables and function names with "is" or "has". You know, something like isLoggedIn, hasAccess or things like that.

But throughout my career I have seen and written code where this convention was just thrown out the window. So let's check out some of these edge cases.

As with all rules, there are exceptions and it might be better to go with that rather than enforcing a convention.

Boolean that verifies that every case is true

const XXX = users.every(user => user.isActive)

XXX will only be true if every user is active. How could we name the variable?

variable	Any good?	Reason
isUsersLoggedIn	🤨	Grammatically incorrect
areUsersLoggedIn	🤔	Custom prefix
isEveryUserLoggedIn	👍	Fits with Array.prototype.every
isEachUserLoggedIn	🥰	Comes off more natural than "every" (depends)

Boolean that verifies that one of many cases is true

const XXX = users.some(user => user.isActive)

XXX will only be true if at least one user is active.

variable	Any Good?	Reason
isUsersActive	🙁	Grammatically incorrect & ambiguous
isAtLeastOneUserActive	😵	Too wordy
isOneUserActive	🤥	Lie. This could imply that there is only one user active. Avoid confusion!!!
isSomeUserActive	👍	Fits with Array.prototype.some
isAnyUserActive	🤗	Comes off more natural than "some" (depends)

Avoid custom prefixes

We covered this in one of the examples before already, but there are more...

variable	Any good?	Reason
wasPaidFor	🤔	Custom prefix
areBillsPaidFor	🤔	Custom prefix
hadHaveHadBeenPaidFor	😶	Ok, I'm just joking at this point
isPaidFor	😊

Affirmative names

variable	Any good?	Reason
isDisabled	🧐	Negative
isNotActive	🤯	Just imagine !isNotActive
hasNoBillingAddress	😞	No need for "no"
isEnabled / isActive / hasBillingAddress	😁	And use it like this !isActive to get the negative

The problem with negative variable names becomes most apparent when you have something like this

if (!account.isDisabled) {
  // ...
}

Just see how much easier this reads

if (account.isEnabled) {
  // ...
}

---

Finally let's take a look at a more complex example.

const isAnyUserOffline = users.some(user => !user.isOnline)

if (isAnyUserOffline) {
  // ...
}

While this works, because of the combination of some and !, it just takes a little more brain power to process this code. An alternative would be:

const isEveryUserOnline = users.every(user => user.isOnline)

if (!isEveryUserOnline) {
  // ...
}

It behaves the same and as long as the data set is small enough I would not worry about the small performance impact.

---

I am sure there is a lot I missed, but I think these are some of the more common cases.

Comments

[Sophie The Lionhart]

Nice! I normally don't find anything valuable in a lot of the more 'basic' articles of advice for newer devs anymore as I've been a dev for over 5 years, but sometimes the right way to name booleans with an 'is', 'has', or whatever eludes me. This is a great little bit of advice and guide! Thanks for the write up and keep up the good work!

[Adam Crockett 🌀]

isGrammaticallyIncorrect

I think this is cultural, I'm a dyslexic programmer from the south west of englind, a place with its own dilect, where "dibber" and "doofer" exist to fill in the names of things we can't remember the name of. A variable assistant if you will. I am fine with the first of each. What I am not fine with is this program not working.

[Carlos Trapet]

if (!hasDibberInDoofer)

I love it!

[Adam Crockett 🌀]

You my friend have invented the new foo bar!

[Adam Crockett 🌀]

Shall I use it in a sentence.

Wife of mine: "pass me the doofer"

Me: 🥺

Wife of mine: "you know that doofer over there" (she doesn't point)

Me: bring an assortment of just about anything in reach.

Wife of mine: "for god sake, do I have to do everything myself"

Me: 😤🤦‍♂️🚶

So there you go, never visit Bristol, it's confusing just like naming variables.

[Anita Graham]

I am from the South West of Australia (and not dyslexic, to the point of pedantry), and we would say "doover" for that sort of placeholder word. (Mum had Irish grandparents on all sides, so I assumed it came from there).

The full name of a doover is a "dooverlacky". Mentally I associate "doover" with "horse doover", which is a variation of "hors d'oeuvres", so not at all connected.

[Adam Crockett 🌀]

Woah this wouldn't surprise me if doofer is one and the same thing. Today I learned 😁

[Yuval]

Should replace foo and bar :)

[Brad]

As they say, one of the hardest things with programming is naming stuff. Great article, I'll have to re-think my naming conventions in the future now 😄

[AmberJ]

Love it!

[Michael Z]

That was not the intention of this article and I am sorry you feel that way. I wanted to share tips for something I personally struggled with in the past and know others have too.

I try not to be picky in code review and don't bother with the things (grammar, spaces, semicolons, commas, etc.) you mentioned.
If a name is confusing I might leave a comment with a suggestion, but by no way enforce any of this stuff, it's all subjective.

[Michael Z]

Ah yea, I was kind of mixing examples in the last one.

[Paddy3118]

Since it is a group of things that may be active, I'd use allActive, anyActive, noneActive, oneActive,...

[Paddy3118]

You can also use gt, ge, lt, le, eq then a number as prefixes for greater-than, greater-than-or-equal, less-than, less-than-or-equal, equal

Something like:

le3Active = activeCount(active) <= 3
gt4Active = activeCount(active) > 4

[Christian]

oof. I read this as "Le Three Active"

[Jarod Brennfleck]

I don't think it actually should matter how your variable names are prefixed. Particularly with "custom prefixes" if it sounds more correct for the usage of the variable, then use it!

If the boolean is a confirmatory boolean and is reset when accessed, the by all means, use "was": enter.wasKeyPressed.

Just my 2¢. Otherwise, a fun read! 🤙

[Michael Z]

Yes that's true, I added it to the article that going with an exception is better than enforcing a convention where it makes sense.

[Christian]

enter.keyWasPressed

[Volodymyr Liutkin]

enter.pressed

[Nikodem Zawirski]

This would imply the key is constantly pressed.

[Luigi Minardi]

isTwoLoggedIn?
areTwoLoggedIn?
isThereTwoLoggedIn?

What should it be? Any other option?

[Michael Z]

That's a tough one.
What came to my mind was also
isPairLoggedIn
isPairOfUsersLoggedIn

Never ran into this case before though :D

[David Latty]

Horrid

[Stepan Stulov]

Two of whom? :)

twoUsersAreLoggedIn

[David Latty]

Good stuff

[Marko Vujanic]

You changed my mind with

Code is set of comands, it dosent ask questions it answers them.

Following that logic, you don't really need is as prefix, and naming of boolean follows the logic nicelly, much more readable, becouse I tryed changing all is to 'command', suprisingly it's just much more readable and parsable in by my head.

isSendEmailFetching -> (request is made to job to send email)
sendingEmail

I wonder what do you think about using transitive verb like this?

Thank you

[Stepan Stulov]

Alternatively, in passive voice, emailIsBeingSent.

[Rong Sen Ng]

Sometimes, one can be prefixed with has or did.