Hacker News Reader

Comment by smcl | Hacker News Reader

Unfortunately your example doesn't illustrate the point very well:

    if (grass_is_green) { ... }

    if (grass_is_green != 0) { ... }

    if (grass_is_green == 1) { ... }

The one with the implit comparison to zero is more readable

View on HN

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.

oh my god, this is horrific. I suppose you are just trolling. There's no way this can be an accepted practice anywhere.

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;
    }

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.

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.

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

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)

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.

   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.

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.

Reply on news.ycombinator.com