6 ms·

Yes, it is very easy to get absorbed in a mindless, repetitive task. You'll feel superficially productive afterwards, but what did it all amount to? I once spe

Yes, it is very easy to get absorbed in a mindless, repetitive task. You'll feel superficially productive afterwards, but what did it all amount to? 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.

yobert 6y ago
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.
- legerdemain 6y ago
  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.
rzzzt 6y ago
What did you change it to?
- muricula 6y ago
  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-vulnerability-in-35-easy-steps-or-less/ https://windows-internals.com/exploiting-a-simple-vulnerabil... When writing C or C++, never compare against true.
  - HeyLaughingBoy 6y ago
    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.
    - stonemetal12 6y ago
      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
    - closeparen 6y ago
      Nonzero values are truthy. You can use them bare in predicates. But they are not "== true."
- serial_dev 6y ago
  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
  - rzzzt 6y ago
    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.
    - HeyLaughingBoy 6y ago
      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 ==
      - zentiggr 6y ago
        That's not rare, anyway... unless the linter can flag == <bool>, and suggest fixes.
      - MauranKilom 6y ago
        Commonly called "Yoda conditions": https://en.wikipedia.org/wiki/Yoda_conditions https://en.wikipedia.org/wiki/Yoda_conditions
robocat 6y ago
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)`.
- _kst_ 6y ago
  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.)

yobert 6y ago

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.

legerdemain 6y ago
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.

rzzzt 6y ago

What did you change it to?

muricula 6y ago
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-vulnerability-in-35-easy-steps-or-less/ https://windows-internals.com/exploiting-a-simple-vulnerabil... When writing C or C++, never compare against true.
- HeyLaughingBoy 6y ago
  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.
  - stonemetal12 6y ago
    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
  - closeparen 6y ago
    Nonzero values are truthy. You can use them bare in predicates. But they are not "== true."
serial_dev 6y ago
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
- rzzzt 6y ago
  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.
  - HeyLaughingBoy 6y ago
    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 ==
    - zentiggr 6y ago
      That's not rare, anyway... unless the linter can flag == <bool>, and suggest fixes.
    - MauranKilom 6y ago
      Commonly called "Yoda conditions": https://en.wikipedia.org/wiki/Yoda_conditions https://en.wikipedia.org/wiki/Yoda_conditions

robocat 6y ago

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)`.

_kst_ 6y ago
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.)