DEV Community

loading...

Discussion on: Tips on naming boolean variables - Cleaner Code

Collapse
stepanstulov profile image
Stepan Stulov • 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:

bool userIsActive = user.isActive (word order preserved)
bool isUserActive = user.IsActive (re-arranged, statement suddenly became a question)

In short: good (although cumbersome) standards but wrong interpretation of them. The only standard you really need for booleans is an affirmative statement that evaluates to either true or false. That's it. Is, are, has, was, did, has been, will, should, must, can, wants, beats, is extrapolating, will have been jeopardized: 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

Collapse
rob2d profile image
Robert Concepcion III • Edited

I mostly agree with you that code readability should be one of the #1 priorities, but at the tend of the day it depends on the context -- also the whole "when in rome" thing.

I'll give you just another perspective: in my situation, I don't use Typescript at my every-day-work, so things are weakly typed, and the IDE auto-prediction works relatively well with VSCode.

Because of that, using is/has/should gives several benefits (magnified in a weakly typed language):
-> auto-prediction is actually very helpful when there's no ESDoc annotation written in common code.
-> consistency, and knowing immediately what something is (though I'd agree and enjoy to work on more other-people's code which is thought out to read-well and flow well as you seem to encourage). There's an aspect of things where if you learn to speed read, the effect when you're glancing over words implies that you catch the first-and-last-part-of-words.
-> when interfacing APIs/other things, getters/setters are easy to automate code with (at least for JS/Ruby), and it's easy to write linter rules on weakly typed languages.

Collapse
dvddpl profile image
Davide de Paolis • 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)

Collapse
qodunpob profile image
Konstantin • 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?