This is completely another level of "issues" than other problems in this thread. During code review I'd only mention it as a nit. The longer form is correct and the only downside is that's a bit longer. It doesn't mess up code modularity or affect maintainability in a noticeable way.

Well, assuming that the language doesn't have any quirks in this area - e.g. in Java your statements aren't equivalent for a Boolean x.

Nitpick (as in general you are right regarding java as well): I’m fairly sure they are the same for java in this instance. Both will convert Boolean to boolean, throwing an NPE if it was a null.

Ha, that's true, thanks! I guess my Java-fu is weak these days :)

They're not equivalent in many languages (JS, C++/swift with operator overloads, if x is nullable etc. etc.).

It's been awhile since I absorbed the weird programming norm that "real programmers use the !x form!" but even after 10+ years of !x , I still find ==false more readable.

I agree. To me, its simpler to understand. Suppose x is a bool, reading the code, I say to myself "if not true..." or "if not false..." and my ape brain gets confused on what happens if its not true or not false.

Reading "if true == false" or "if false == false", it becomes much clearer what we're testing here and I understand it instantly.

If the statement is "if (!isGreen)", it's much clearer to say "if is not green" than it is to say "if is green is false". Putting == true or == false makes you convert a clear statement "is green" into "true" or "false" instead of just being a natural English statement. It would be like saying in conversation, "I want to go to the store is false" instead of "I don't want to go to the store".

> If the statement is "if (!isGreen)", it's much clearer to say "if is not green" than it is to say "if is green is false"

I agree that when you read it, it's clearer. And yet I still prefer "if(isGreen == false)" for reasons of clarity in another sense.

The "!" being right next to the "(" makes it easier to miss the "!" when scanning quickly through the code, hence reading the logic the wrong way round and seeing "(isGreen" instead of "(!isGreen". And that's enough of a risk to ignore the readability advantage of "(!".

(Edit: To be clear, I don't suggest "== true" for the opposite cases, as the lack of a "!" in those means the risk is gone)

It also helps readability if the ! is before a function name that doesn't follow the right naming convention for it. One of my pet peeves in C is "if (!strcmp(a, b))". "!strcmp" I read as "not string compare" and I would expect it to mean that the strings don't compare when it means the exact opposite. This is true of anything following the "0 means success, anything else is an error condition" error handling scheme. So I use "if (strcmp(a, b) == 0)" instead because the "==" makes look at what value it's being compared to specifically and I make fewer assumptions.

Even if the not operator in the language you're writing in happens to be the actual word 'not' ?

My whole career has been C++ and shader languages, so this really hasn't come up for me. I imagine it being a real word would improve readability greatly.

Even more common seems to be

  if (x == true)

which always seem to come with some argument how it is "more clear".

I have started to ask people straight away to change to

  if ((x == true) == true)

which following the same argument should be even more clear.

I wrote code like that sometimes. Equaling false is more specific, depending on language. There are many falsey things that are not false themselves.

In some languages these do different things, right? (Or if someone did something horrendous with operator overloading)

As much as people push the more succinct if(x)/if(!x) style of expression, I don't know that it is better. Now if your example was if(is_a_thing) then maybe it reads better. Add to that the possibility of three value logic and I could lean more to the if(x == false) style.

The worst one is "if x=true", which to me says the writer doesn't know what the if statement does...

That said, if x is data read from elsewhere that just happens to be boolean, I can write code like that in Python.

The UW intro CS courses call the `if (x)` form "Boolean Zen", which I've always enjoyed.

I've seen this in Ruby and Elixir that drives me a little nuts:

  if !is_nil(foo)

While it may not matter in many circumstances, this is not the same as "if foo", because false is not nil.

It's true but in 10+ years of writing Ruby it hasn't mattered in _any_ circumstances I've come across. I also assert that having a boolean where `nil` is meaningfully different than `false` is a smell and should be avoided.

Some of that might be Python habits which is terrifying for completely different reasons.

!x is not equal to === false.