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

Is naming Booleans that start with "is" bad practice now? M开发者_StackOverflowy manager believes that "isAnything" is outdated and poor practice. Is this true?

myManager.isLame ? correct() : incorrect();

---

It's used quite often in a lot of languages, but I don't know if it can be said with certainty that it's the preferred method.

I think consistency and everyone on a given team using the same standards/styles is the important thing to bear in mind.

---

I would not use any hard and fast rules here. Although I find a prefix such as 'Is' useful in identifying a boolean property, there are many cases where 'Is' would not be the best choice.

• Car.HasFlatTyre vs Car.IsFlatTyre
• Cars.AreAllRed vs Cars.IsAllRed
• etc...

The MSDN naming guidelines include the following relevant advice.

Do name Boolean properties with an affirmative phrase (CanSeek instead of CantSeek). Optionally, you can also prefix Boolean properties with Is, Can, or Has, but only where it adds value.

---

isLame() is very common, and I consider it to be not lame. In Java, it's part of the JavaBeans specification, and therefore quite an ensconced practice.

---

It's a matter of style, and I've seen it your way lots of times (and do this myself in many languages).

---

Stylistically, my vote would be for hasValue or isNullOrEmpty. Using clever shortcuts or one-line if statements like that, however, is universally bad. It drastically reduces code readability and in most languages will not lead to any performance gain.

---

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.

---

it would be better if you create boolean variable with clear name

boolean lame;

and make method to check its value

isLame(){
  return lame;
}

It's generally better approach to invoke method over direct access to variable.

---

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.

---

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.