DEV Community

Tips on naming boolean variables - Cleaner Code

Michael Z on October 03, 2019

Originally posted at michaelzanggl.com. Subscribe to my newsletter to never miss out on new content. There is a convention to prefix boolean var...

Read full post

Stepan Stulov • Dec 18 '19 • Edited

This whole naming of booleans is one of the simplest yet most misunderstood conventions in programming.

You seem to be a proponent of naming booleans as affirmative statements, yet you name your booleans as questions. This seems contradictory to me.

isEveryUserOnline? Is he? I don't know, maybe? Are you asking me? Or is anyone standing behind me? Why is code talking to me and making me decide? Code is a set of commands. It answers questions. It doesn't ask them.

Purely linguistically, you don't say "If am I a developer". You say "If I am a developer".

Your isEveryUserOnline variable should be named everyUserIsOnline or allUsersAreOnline. This would truly be affirmative, according to your own standard. This will also read well in English and go well with order of words when using dot notation. Compare:

// Same order, erase the dot and you got yourself a variable name.
bool userIsActive = user.isActive;

// Order changed, statement suddenly became a question.
// Also have to bother about moving words around.
bool isUserActive = user.IsActive;

The only standard you really need for booleans is an affirmative statement that evaluates to either true or false. That's it. Hello, Propositional Calculus. Is, are, has, was, did, will, should, must, can: all just flavors.

As for prefixing for the sake of prefixing, I thought that was called Hungarian notation and is more or less dead, with a few relics still roaming the Earth.

Hope this helps,
Cheers

A-ZC-Lau • Apr 28 '21 • Edited

isEveryUserOnline? Is he? I don't know, maybe? Are you asking me? Or is anyone standing behind me? Why is code talking to me and making me decide? Code is a set of commands. It answers questions. It doesn't ask them.

Seems very pedantic. The word is isn't asking you, it's invoking a question with a binary answer.

userIsActive is a statement. It makes it sound like a constant.

Take for example "Is it 5 o'clock" would invoke a yes/no answer in your mind immediately. If your brain suddenly thinks that the computer is talking to you, rather than you realizing that the variable is actually saving a boolean, it's a problem between chair and keyboard.

Conversely, with your format, "It is 5 o'clock" would be a statement. You don't answer a statement, which makes it seem like a constant.

In fact, I would argue that statements are invocation of action. Because you wouldn't have a statement of "It is 5 o'clock" and then do nothing with it. So the name userIsActive would be a function i.e. userIsActive(), which you would use as in

if (isUserActive) { 
    userIsActive()
}

Stepan Stulov • May 17 '21 • Edited

For invocation of actions in the imperative programming paradigm, with which you (arguably) unbeknownst to yourself operate, imperative mood of verbs is conventionally used. This is what gave imperative programming paradigm its very name.

if (userIsActive)
    SetUserActive(false); // Imperative mood of the word "set"

PS: In an educated and intelligent community such as ours we do not call people "a problem between the chair and the keyboard" just because we disagree. Disagree one may. Insult one may not. Assuming education and intelligence are there in the first place, of course.

Davide de Paolis • Sep 7 '20 • Edited

absoulutely agree. i understand the need for the convention, since ( expecially at the beginning of your career) you are able to immediatly find or recogninze a boolean variable by the fact that starts with is or has, but was never bought into this.
exactly for the reason you mentioned,

is it a question? are you asking me? i don't know, you should tell me!

and because of the many exceptions that make some variables seriously grammatically terrible. I found this post because I was looking for alternatives or way of telling in a Pullrequest that isUserAlreadyExist is a complete NOPE for me...

imho, dimply use conventions when it makes sense, ( possiblly in thex affermative format - like useIsActive - which in my case would become a more natural userAlreadyExists)

Konstantin • Jan 16 '21 • Edited

What about the point that no code ask you but you have asked the data about something and store answer in variable with the same name?

Jamon Jamen • Apr 14 '25

Then I already know the answer and can store it in a variable like userExists or saved. Don't need to ask once again. If I want to ask, I would use IsSaved() or IsExistingUser().

I especially love the pattern with some auto-generated codebase for based on OpenAPI or protobuf specs - the accessors Get prefix irritates me even more.
getIsActive() function always sounds to me as if by invoking this function I will get another function as a result, which will tell me if a user is active if I invoke it.

Adam Crockett 🌀 • Oct 3 '19

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 • Oct 3 '19

if (!hasDibberInDoofer)

I love it!

Adam Crockett 🌀 • Oct 3 '19

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 • Jul 30 '20

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 🌀 • Jul 30 '20

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

Adam Crockett 🌀 • Oct 3 '19

You my friend have invented the new foo bar!

Sophie The Lionhart • Oct 3 '19

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!

Jarod Brennfleck • Oct 5 '19

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! 🤙

Volodymyr Liutkin • Aug 19 '23

enter.pressed

Nikodem Zawirski • Jun 19 '24

This would imply the key is constantly pressed.

Michael Z • Oct 5 '19

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 • Dec 1 '20

enter.keyWasPressed

Michael Z • Oct 4 '19 • Edited

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.

Matthieu L. • Dec 12 '19

Great article, thanks !
Question, how do you name boolean getters ?
I've seen people using booleans like "empty" and getters like "isEmpty()", but I prefer having is/has prefixes for booleans as you say.
I use getters like "getIsEmpty()" for an "isEmpty" boolean, but many people find it akward..

Christian • Dec 1 '20 • Edited

I prefer to leave verbs for functions, such as getters.

let empty = true;

const isEmpty = () => empty;
const getEmpty = () => empty;

Stepan Stulov • Dec 18 '19

Many people do but stand your ground, it's good.

Paddy3118 • Oct 4 '19

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

Paddy3118 • Oct 4 '19

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 • Dec 1 '20

oof. I read this as "Le Three Active"

Kamal • Dec 3 '20

hadHaveHadBeenPaidFor
this made me chuckle on the middle of the day, thank you :))

Luigi Minardi • Oct 5 '19

isTwoLoggedIn?
areTwoLoggedIn?
isThereTwoLoggedIn?

What should it be? Any other option?

Michael Z • Oct 5 '19

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

Never ran into this case before though :D

David Latty • Sep 29 '20

Horrid

Stepan Stulov • Dec 18 '19 • Edited

Two of whom? :)

twoUsersAreLoggedIn

Marko Vujanic • Jul 13 '22 • Edited

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 • Aug 12 '22

Alternatively, in passive voice, emailIsBeingSent.

Brad • Oct 3 '19

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 😄

NikitaArgov • Dec 25 '19

Great article, thank you!

Found it, trying to find idea for naming of boolean "AreContactsShown". Name "isEachContactShown" would be weird - there are no separate contact items.

Any suggestions?

Michael Z • Dec 25 '19

Thanks!

Where are the contacts displayed in? You could maybe use that instead, e.g. isContactListShown

Christian • Dec 1 '20

contactsAreShown, contactsAreVisible, or create an object: contacts.visible

João Marcos Bezerra • Jul 4 '20

Great article, very useful, thanks

Aymon Fournier • Jun 4 '20

what about shouldSave as a boolean prop to a component that would fire the useEffect?

Christian • Dec 1 '20

answering what should save would be easier to understand. recordShouldSave

manishrawat4u • Apr 2 '20

How about naming something which really cannot be smaller? Like an option for
Generate file when user logs in everytime

Volodymyr Liutkin • Aug 19 '23

“when user logs in everytime” isn’t the part of assertion but rather a descriptive requirement. The assertion here is something like fileShouldBeGenerated.