Hacker News Reader

Comment by nayuki | Hacker News Reader

  > There is an implicit "x != 0" in: if (x), while (x), ... etc.
  > An explicit "x != 0" in these contexts serves no semantic purpose.
  > And "x == 0" in these contexts might be better written as "!x".

I disagree with this advice because the idea is not portable across languages.

For example, if we let the variable x hold the integer value 0, then:

  Java    'if (x)' is a compile-time type error.
  Python  'if x:'  is falsy, similar to C.
  Ruby    'if x'   is truthy!

View on HN

While this is technically correct, idiomatic javascript differs from idiomatic ruby, which (that is the point) differs from idiomatic C.

So either no idioms are correct, or it is correct to apply the idioms pertaining to the language of choice.

The advice in the article is too broad because there are times when the comparison is not meant in the truthy/falsy sense. For example, strcmp and friends return 0 if the strings are equal, less than 0 if str1 is lexically less than str2, and more than 0 if str1 is lexically greater than str2.

So if(!strcmp(str1,str2)) is a valid way to check for equality, but I think the negation makes it confusing; it is tempting to intuitively read it as checking if the strings are not equal. if(strcmp(str1,str2) == 0) is the better choice.

Calling it (eg) strdiff instead would help here, if(!strdiff(str1,str2)) matches the intuitive interpretation.

It's a three way comparison, not an equality one. If you treat it like that then the return value makes more sense.

Sure - thats why it shouldn't be str_ne or similar. strDIFF (or rather, strcmp) returns the direction in which strings DIFFer - less than (negative), greater than (positive), or equal (zero).

Do you stick to features portable across all languages for all your code?

Maybe they only write polyglots :)

Yes. This is why I exclusively write polyglot source files, so you can choose to compile my code in either c++ or php or bash or whitespace.

Jokes aside, polyglot source files are pretty cool, and generally things like abuse of the c++ preprocessor are really neat to see, if completely unwise to do in production.

It's not meant to be portable. It's just that C is a low-level, weakly-typed language where everything is bytes and bits, and every pointer may be null at any moment. Disregarding type-safety is OK for C, so it's handy to conflate 0 and false (after all, bools are isomorphic to positive numbers modulus 2). It's these other languages who are in the wrong because any high- or medium-level language must have proper Option and Bool types without null or false infecting every type out there.

Yeah... Ruby is in the wrong there. Not even js does that

Insisting if takes a bool like java does is perfectly acceptable. But just taking a 0 value and making it "true" makes sense only in Bash?

It depends on what the set of falsey values is for that language.

E.g. in Common Lisp, the only falsey value is NIL (the empty list). This is easy to understand, easy to remember, and straightforward in practice because idiomatic Lisp does a lot of list operations. It wouldn't make sense for 0 to be truthy, because that's a legit value, and NIL represents the absence of a value.

I don't know what values are falsey in Ruby, so I can't comment on it.

Lua does this as well, and I quite prefer it.

If I return a number or nil, I want to check `if ret`, not `if type(ret) == "number"`. The latter suggests that it might be some other type‡, the former that it might be missing entirely.

A language which provides a proper Boolean has no need for the association between zero and falseness, it is a conflation of levels which can lead to subtle bugs.

‡ yes, nil is also a type. I mean some other type of type.

erlang and erlang VM languages come with 0 being truthy, and the only falsey values are false and nil. I had a junior python programmer disagree with that and within 3 weeks of onboarding him we found a place where it made sense for 0 to be a truthy value. I believe it was a place where we had an options list. One of the options was a value that is settable to zero. In elixir:

    timeout = options[:timeout] || :infinity

if zero is falsy, you can be royally screwed with that code, if timeout should be settable to zero (definitely a thing).

It makes a lot more sense when you consider that all values in Ruby would be pointers in C. And if x is a pointer to int, if(x) is still checking whether the pointer itself is null, not whether the int it points to is 0.

Lua does that too. Lua only has two values considered false, nil and false. All else, in a Boolean context, evaluates to true.

Scheme recognizes all values except #f, including 0, '() which is how you say nil in Scheme, and "", as true in conditionals. As it should be; having to guess whether something might be falsy is a pain in my rear solved by having precisely one falsy value. As a bonus you can use #f as a sentinel value to denote the absence of a valid parameter or return value when a valid value would be some non-boolean object, and then check for validity with a simple (if x ...)

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.

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

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