4 ms·

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 comp

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.

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.