Naming booleans

Question

If I only want to check if something is impossible or not (i.e., I will not be using something like if(possible)), should I name the boolean notPossible and use if(notPossible) or should I name it possible and use if(!possible) instead?

And just to be sure, if I also have to check for whether it is possible, I would name the boolean possible and use if(possible) along with else, right?

Answer 1

You should probably use isPossible.

Negative names for booleans like notPossible is a very bad idea. You might end up having to write things like if (!notPossible) which makes the code difficult to read. Don't do that.

Answer 2

Whichever is easier to read in your specifc application. Just be sure you don't end up with "if (!notPossible)".

Answer 3

I tend to err on the side of positivity here and use possible. It means someone can't write some code later that does this...

if (!notPossible)

Which is unreadable.

Answer 4

I think it's considered preferable to avoid using negatives in variable names so that you avoid the double negative of if(!notPossible).

Answer 5

I recommend using isPossible. It just seems to make a lot of sense to use 'is' (or perhaps 'has') whenever you can when naming boolean variables. This is logical because you want to find out if something is possible, right?

Answer 6

I like to name booleans with consistent short-verb prefixes such as is or has, and I'd find a not prefix peculiar and tricky to mentally "parse" (so, I suspect, would many readers of the code, whether aware of feeling that way or not;-) -- so, I'd either name the variable isPossible (and use !isPossible), or just name the variable isImpossible (many adjectives have handy antonyms like this, and for a prefix has you could use a prefix lacks to make an antonym of the whole thing;-).

Answer 7

I agree that negatively named booleans are a bad idea, but sometimes it's possible to reframe the condition in a way that's positive. For example, you might use pathIsBlocked rather than cannotProceed, or rather than isNotAbleToDie you could use isImmortal.

Answer 8

I generally try to name my flags so that they will read as nicely as possible where they are being used. That means try to name them so that they won't have to be negated where they are used.

I know some folks insist all names be positive, so that people don't get confused between the negations in the name and those in their head. That's probably a good policy for a boolean in a class interface. But if its local to a single source file, and I know all the calls will negate it, I'd much rather see if (impossible && ...) than if (!isPossible && ...).

Answer 9

You should name it for exactly what is being stored in it. If you're storing whether it's possible then name it isPossible. If you're storing whether it's impossible name it isImpossible.

In either case you can use an else if you need to check for both cases.

From your description it seems more important to you to check for impossibility so I'd go with isImpossible:

if(isImpossible)
{
    // ...
}
else
{
    //...
}