Is using "is" to name Boolean variables bad practice?

user_518116 0
Viewed 25156

Is naming Booleans that start with "is" bad practice now? My manager believes that "isAnything" is outdated and poor practice. Is this true?

myManager.isLame ? correct() : incorrect();
boolean naming variables
9 Answers

According Alibaba-Java-Coding-Guidelines

8.[Mandatory] Do not add 'is' as prefix while defining Boolean variable, since it may cause a serialization exception in some Java frameworks.

Counter example: boolean isSuccess; The method name will be isSuccess() and then RPC framework will deduce the variable name as 'success', resulting in a serialization error since it cannot find the correct attribute.

user_133389360

It is very useful to see from a struct dump or from the result of an SQL SELECT query what an actual value means. For example, if you just see mandatory is 1 then you cannot be sure what it means:

  • a boolean value where 1 represents true (as opposed to false)
  • the number of mandatory items is 1 (as opposed to 2 or 3)

A name like isMandatory makes it clear that this is a boolean value.

On the other hand, depending on the meaning of the word that follows the prefix, it makes sense using other prefixes like isSomething, hasSomething, doesSomething, etc. For example, isValid, hasChildren, doesExist, and so on. Confusing them, like isChildren, would be grammatically incorrect and annoying.

Therefore, don't enforce using is. Anything that suggests a true/false-like meaning is OK. Like wasChecked, hadInvestigation, etc.

I use this rule for naming variables, database fields and functions/methods too.

Not strictly linked to the question but relevant:

  1. I like to call variables and fields that represent cardinality like numOf<Whatever>. For example, numOfChildren, numOfItems, and so on.

  2. I like to name the values that represent a timestamp something like <happened>At, for example, createdAt, updatedAt, approvedAt etc.

user_38238260

Follow a language's documented convention. If there is no convention:

Omit type info in variable naming altogether.

That includes is for booleans.

boss.lame ? limp() : sprint()

For languages with strong typing the information is redundant.

For languages without strong typing the information is still redundant because IDEs and all of the various tools available now help with typing without having to convolute the names.

is is a verb. is_lame() should be an accessor method that returns a boolean value.

user_10387260
Related