I once spent several hours grepping and changing every instance of `if (foo != true)` in a multi-million LOC codebase. Was it a good use of my time? Not at all.
I once spent several hours grepping and changing every instance of `if (foo != true)` in a multi-million LOC codebase. Was it a good use of my time? Not at all.
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.
In more weakly typed languages null/NaN special cases and type conversion rules make it very hard to safely rewrite `if (foo != true)`.
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.)
When writing C or C++, never compare against true.
Too lazy to look it up right now, but my recollection is that in C, 0 is False and anything else is True.
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