Prefixes

Some style guides advocate for booleans to use a natural language prefix, such as:

• isLoggedIn rather than loggedIn
• isActive rather than active
• isReadable or canRead rather than readable

I’ve also seen some people advocating for member variables to named without a prefix then for the getter and setter to be prefixed.

I will include prefixes where I think it improves readability, but will not try to coerce a name into some isState format, which I think is a common problem. For example, uploadsPaused is a better name than isUploadsPaused or areUploadsPaused, because it reads better when used:

if(uploadsPaused){
  // Do something
}

if(isUploadsPaused){
  // Do something
}

if(areUploadsPaused){
  // Do something
}

Tense

Sometimes booleans represent state for a thing that happened in the past. I’ve seen people call it bad form for variables to be named with past and future tenses, such as wasCancelled or willBeUploaded.

In general I think this depends on the situation. It can be ok for booleans to be named in the past-tense to reflect things that have happened. This is particularly true when you’re reasoning about the result or state of a procedure. For example:

• wasSuccessful
• wasSent
• wasErrorThrown

However, sometimes you’ll find things that represent the current state expressed as a past-tense. In those cases the variable should be renamed to present tense. For example:

• userPausedUploads could be replaced with uploadsPausedByUser
• wasSuccessful could be replaced with success or isComplete
• wasSent could be replaced with isSent
• wasErrorThrown could be replaced with failed or hasError

So while present-tense is preferred, readability remains king. If using past-tense makes it easier to follow the flow of control, then past-tense can be used.

I have never found a situation where it was acceptable to have a “future tense” variable name.

Affirmative vs. Negative

Some people have asserted that booleans should always take the affirmative form. For example:

• success instead of failed
• loggedIn instead of loggedOut
• isOpen instead of isClosed

It’s not about avoiding clearly preposterous names like notSet or isUnset. Those are avoided because it can create a double-negative situation, requiring the reader to evaluate the meaning of things like !isNotFound.

Instead this is built on the idea that the human brain ‘prefers’ to think and reason in terms of cause and affect. A “cause” is when the input to a system deviates from the base state: e.g. a button is pressed to open a door. The base state for the button is “not pressed”, the deviation is “pressed”. Humans tend not to think of things as continually being “on” (Gravity is a good example).

This has been translated into a theory that it’s always better to think and reason about code if all booleans are expressed in the affirmative form, named such that false is the base state.

In my experience this is generally true and most things are better put into the affirmative form.

Final Thoughts

As mentioned above, readability is king. It’s not too hard to go thought a project and find a bunch of badly-named booleans. Distilled into tips:

• Try to name your booleans such that they’re clearly a true/false query.
• Try to name your booleans such that it’s clear what state corresponds to true and false.
• Try to name your booleans in the present tense.
• Try to name your booleans in the affirmative form, such that there is no logical negation in the name.
• Above all else, readability is king.