I think it can be good for you to do this kind of work once in a while. I like to sort my M&Ms.

But! From a technical perspective, I would never ever do this. It's likely to causes merge conflicts on every single pending branch anyone has. I would recommend only changing the area you are working on. Leave it better than you found it, but don't rock the canoe so to speak.

This is one good purpose for video games. If you have an uncontrollable urge to do something mindless, at least do it safely in a simulated environment.

Definitely not a good use of your time in many languages! Because `if (!foo)` is only equivalent given a language where foo can only be a Boolean type (I’m guessing you were using Java?).

In more weakly typed languages null/NaN special cases and type conversion rules make it very hard to safely rewrite `if (foo != true)`.

In C, for example, "if (foo != true)" is not necessarily equivalent to "if (!foo)" -- but the latter very probably reflects the author's intent more accurately.

For example, an int with the value 42 is logically a "truthy" value, but the test "if (foo != true)" will succeed. Someone who would write "if (foo != true)" very likely didn't know that, and should have written "if (!foo)".

On the other hand, blindly fixing bugs like that has a good chance of changing the program's behavior, and possibly breaking it.

(All this assumes that the identifier "true" is visible. In C, this requires "#include <stdbool.h>" -- unless the programmer defined it explicitly.)

What did you change it to?

This is pure speculation, but they may have changed it to foo==false. In C a boolean is just a byte which conventionally has the values 0 or 1, but an attacker which controls a boolean can give it the value of 2, and 2!=true and 2!=false. This has lead to real exploits: https://windows-internals.com/exploiting-a-simple-vulnerabil...

When writing C or C++, never compare against true.

I'm not sure that's right.

Too lazy to look it up right now, but my recollection is that in C, 0 is False and anything else is True.

Nonzero values are truthy. You can use them bare in predicates. But they are not "== true."

if 47 evaluates the true branch. So in that sense you are correct, however standard C99 (the above mentioned bug uses win32's TRUE which is defined the same way) does #define true 1 therefore 47==true is false, even if 47 is true when evaluated.

int a = 47;

if a is true

if a == true is false

if a == false is false

int b;

b = a == true; b = 0

b = a != true; b = 1

b = a == false; b = 0

b = a != false; b = 1

I'd guess if(!foo). It makes sense in some languages where the value can only be either true or false. It will lead to nasty bugs if the value can be null, or the language has truthy-falsy values and the condition accepts non bool values

You and muricula's sibling comment is the reason I asked :) Occasionally it is hard to spot the "!" between "if" and "(", and having to figure out if it is an omission or it was deliberate. I was wondering if spelling it out as "foo == false" is worthwhile.

At one job I had, our programming standards dictated that we would have to write "if (false == foo)" to account for the case where someone accidentally types = instead of ==

Commonly called "Yoda conditions":

https://en.wikipedia.org/wiki/Yoda_conditions

That's not rare, anyway... unless the linter can flag == <bool>, and suggest fixes.