42

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();
worked
  • 5,762
  • 5
  • 54
  • 79
  • 4
    In what language? For instance, in Java using "is" for boolean properties is the preferred way of doing it. – aroth Aug 05 '11 at 02:43
  • I agree that your manager is lame. I use it all the time and nobody's ever said anything to me. – NullUserException Aug 05 '11 at 02:50
  • 2
    `isLame()` looks like a method, not a variable ;-) For *variables* I very rarely ever use an `is` prefix. However, on an *exposed method or accessor*, the "is" in the name *can* add value -- *if it does add value then it is warranted in my opinion.* (However, I find it perfectly valid to omit "is" or use another builder such as "has" *all based on the value* of the given name.) –  Aug 05 '11 at 02:53
  • I use `is_lame` or `has_something` – Paranoid Android Jun 26 '13 at 08:54

9 Answers9

27

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.

Tim
  • 28,212
  • 8
  • 63
  • 76
  • 2
    I agree fully with the team standards concept. Perhaps if my manager had stated it that way to begin with, I wouldn't have posted this question. – worked Aug 05 '11 at 02:55
26

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.

Scott Munro
  • 13,369
  • 3
  • 74
  • 80
3

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.

Ernest Friedman-Hill
  • 80,601
  • 10
  • 150
  • 186
  • The question is about `object.isBooleanProperty` not about a function returning a boolean. While I 100% agree about the function naming, I don't when it comes to boolean properties. – Mozgor Mar 16 '22 at 14:59
2

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.

whoblitz
  • 1,065
  • 1
  • 11
  • 17
  • 12
    Please. There is nothing wrong with using a ternary if. It has nothing to do with the question. – Isius Jul 10 '14 at 13:43
  • 2
    In my company we all were against those one-line statements. Then a new guy came in our team, who always used that stuff. Once we all got used to it, it _is_ actually easier to read. You should never make your expressions too complex of course. But using nice shortcuts to keep the code short and clean _improves_ readability a lot. Especially C# develops a lot in the last few years. You should stay up to date with all new shortcuts or otherwise you won't be able to read the code in 10 years. (I didn't tell anyone to _use_ all the new shortcuts. But you should know them.) – ecth Feb 01 '17 at 07:26
2

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.

Csongor Halmai
  • 3,239
  • 29
  • 30
2

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

Chris Gregg
  • 2,376
  • 16
  • 30
1

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.

Roman Marusyk
  • 23,328
  • 24
  • 73
  • 116
achyut pokhrel
  • 694
  • 5
  • 5
0

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.

None
  • 5,491
  • 1
  • 40
  • 51
  • 1
    JavaBean convention dictates that `is` be used in the place of `get` when referring to boolean fields. There are ***quite a lot*** of libraries which are predicated on JavaBeans conventions. – Makoto Dec 03 '18 at 22:52
0

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.

Chuck Lu
  • 173
  • 12
  • 1
    One company using one particular framework that has a bug (or a bad assumption about naming) is not a strong argument against an otherwise easy-to-read and self-explanatory naming convention. – Csongor Halmai Feb 28 '23 at 02:26