5 ms·

Completely agree... but the most serious issue is that it does not read well. Consider how you would read it: "if grass is green ..." is effectively shortened

Completely agree... but the most serious issue is that it does not read well. Consider how you would read it: "if grass is green ..." is effectively shortened to "if grass ...". This makes no sense. I always use explicit conditions and consider "if(x)" and antipattern and have done since I was learning C back in the mid eighties.

smcl 7y ago
Unfortunately your example doesn't illustrate the point very well: if (grass_is_green) { ... } vs if (grass_is_green != 0) { ... } or if (grass_is_green == 1) { ... } The one with the implit comparison to zero is more readable
- zormino 7y ago
  Certain industries also have guidelines that chime in on this issue. Where I work, we have to create defines for TRUE and FALSE, and everything needs to be compared to them. Essentially making things look like if (bool_name == TRUE) There is no ambiguity, and it forces you to handle exactly equal to 1 and not equal to zero separately. if (bool_name == TRUE) and if (bit_field_value > 0) are logically different even if they can be simplified to the same thing.
  - enriquto 7y ago
    oh my god, this is horrific. I suppose you are just trolling. There's no way this can be an accepted practice anywhere.
    - userbinator 7y ago
      As someone who has actually worked with a codebase with plenty of such expressions, I suspect it was really an "accepted practice" at some point in time, stemming from a mindless interpretation of the "be explicit" guideline taken too far. The worst part is that sometimes these redundancies grow and combine to create even more confounding expressions, frequently resulting in monsters resembling this: if ( ((((!(var)!= FALSE)) != TRUE)) ) { return FALSE; } else { return TRUE; }
  - marcoperaza 7y ago
    That is bad practice IMO because it makes it easy to accidentally introduce bugs and produces code that a reader will misinterpret, making it harder to find bugs. The better approach is to always compare against FALSE, because that avoids the ambiguity of == TRUE only catching a single truthy value out of the millions of possible truthy values, contrary to the well-known semantics of C. If you really need to distinguish between 1 and other truthy values, then just compare against 1 explicitly. Don't muddle the concept of truthiness.
    - zormino 7y ago
      All times where a Boolean value would be assigned, it must be explicitly checked and then set to either TRUE or FALSE. The reason is for writing embedded code that doesn't depend on a specific compiler or architecture, which is important when code that was written in the 80s is still getting used everyday in new safety critical systems, where any kind of standard libraries are forbidden. I agree it's not the best but it's definitely not uncommon.
  - kazinator 7y ago
    In C, comparing boolean-like variables to true and false constants is bad practice. The comp.lang.c FAQ touches upon this: http://c-faq.com/bool/bool2.html http://c-faq.com/bool/bool2.html
    - mar77i 7y ago
      I find myself both agreeing and disagreeing here. I put comparators compulsively everywhere, especially because I switch between multiple languages, but I also don't trust my memory and keep a close eye on the documentation, therefore I usually end up with if (isupper(c) != 0)
      - kazinator 7y ago
        The real tripper-upper with isupper (and siblings) is that the argument is of type int and must have values in the range 0 to UCHAR_MAX (those of unsigned char) or else EOF. Anything else is undefined behavior.
      - enriquto 7y ago
        if (isupper(c) != 0) This code is illegible to me. How do you read it aloud? "if c is upper is not zero" ? It makes no sense. Compare it with the normal way of writing "if(isupper(c))" which is pronounced "if c is upper", which is perfectly clear, grammatical English.
- kazinator 7y ago
  The one with the implicit comparison is more readable because it's closest to simulating the test of a Boolean variable. The other two leave the reader with the lingering suspicion that the variable takes on two or more values. The latter more so than the former.

smcl 7y ago

Unfortunately your example doesn't illustrate the point very well: if (grass_is_green) { ... } vs if (grass_is_green != 0) { ... } or if (grass_is_green == 1) { ... } The one with the implit comparison to zero is more readable

zormino 7y ago
Certain industries also have guidelines that chime in on this issue. Where I work, we have to create defines for TRUE and FALSE, and everything needs to be compared to them. Essentially making things look like if (bool_name == TRUE) There is no ambiguity, and it forces you to handle exactly equal to 1 and not equal to zero separately. if (bool_name == TRUE) and if (bit_field_value > 0) are logically different even if they can be simplified to the same thing.
- enriquto 7y ago
  oh my god, this is horrific. I suppose you are just trolling. There's no way this can be an accepted practice anywhere.
  - userbinator 7y ago
    As someone who has actually worked with a codebase with plenty of such expressions, I suspect it was really an "accepted practice" at some point in time, stemming from a mindless interpretation of the "be explicit" guideline taken too far. The worst part is that sometimes these redundancies grow and combine to create even more confounding expressions, frequently resulting in monsters resembling this: if ( ((((!(var)!= FALSE)) != TRUE)) ) { return FALSE; } else { return TRUE; }
- marcoperaza 7y ago
  That is bad practice IMO because it makes it easy to accidentally introduce bugs and produces code that a reader will misinterpret, making it harder to find bugs. The better approach is to always compare against FALSE, because that avoids the ambiguity of == TRUE only catching a single truthy value out of the millions of possible truthy values, contrary to the well-known semantics of C. If you really need to distinguish between 1 and other truthy values, then just compare against 1 explicitly. Don't muddle the concept of truthiness.
  - zormino 7y ago
    All times where a Boolean value would be assigned, it must be explicitly checked and then set to either TRUE or FALSE. The reason is for writing embedded code that doesn't depend on a specific compiler or architecture, which is important when code that was written in the 80s is still getting used everyday in new safety critical systems, where any kind of standard libraries are forbidden. I agree it's not the best but it's definitely not uncommon.
- kazinator 7y ago
  In C, comparing boolean-like variables to true and false constants is bad practice. The comp.lang.c FAQ touches upon this: http://c-faq.com/bool/bool2.html http://c-faq.com/bool/bool2.html
  - mar77i 7y ago
    I find myself both agreeing and disagreeing here. I put comparators compulsively everywhere, especially because I switch between multiple languages, but I also don't trust my memory and keep a close eye on the documentation, therefore I usually end up with if (isupper(c) != 0)
    - kazinator 7y ago
      The real tripper-upper with isupper (and siblings) is that the argument is of type int and must have values in the range 0 to UCHAR_MAX (those of unsigned char) or else EOF. Anything else is undefined behavior.
    - enriquto 7y ago
      if (isupper(c) != 0) This code is illegible to me. How do you read it aloud? "if c is upper is not zero" ? It makes no sense. Compare it with the normal way of writing "if(isupper(c))" which is pronounced "if c is upper", which is perfectly clear, grammatical English.
kazinator 7y ago
The one with the implicit comparison is more readable because it's closest to simulating the test of a Boolean variable. The other two leave the reader with the lingering suspicion that the variable takes on two or more values. The latter more so than the former.