Hacker News Reader

Comment by crazygringo | Hacker News Reader

Question: am I the only one who's driven nuts by "if"s that come after the "then" part? E.g.:

    do_something(with, these, args) if im_supposed_to

I mean, the processor/interpreter always needs to evaluate the "if" first, so what purpose does it ever serve to put it after the "then"? To me, it just confuses things because it feels like code is getting executed backwards -- like crossing an intersection, and then checking to see if the light is green.

I know it works "in English" ("do this if that"), but when I scan other people's code I'll sometimes completely miss the "if" (sometimes it's just off the screen).

Are there any examples where this reverse-if actually helps, instead of harming, code intelligibility?

View on HN

Postfix conditionals are pretty nice for conditional statements that are particularly unlikely to happen. Imagine, in a function body:

    read(file)
    write(file) unless terriblyUnlikelyThingHappens
    return results

... it helps to keep the expected main-line flow of your instructions reading smoothly -- much the same as the way you'd tend to use it in English. Doing it the "normal" way instead:

    read(file)
    if (!terriblyUnlikelyThingHappens) {
      write(file)
    }
    return results

... makes it a bit more difficult to follow what should be going on in the function.

I personally find that I end up reading more lines of code than I need to.

When scanning and I see

    If (condition) { perform_some_action(foo, bar, baz); }

And I know condition is false I can ignore what follows but

    perform_some_action foo, bar, baz if condition

I now have to stop and parse the entire line. But not only that, because it can appear at the end I need to parse every line to make sure I don't get caught by some if or unless. Short lines are easy sure but it's still annoying to me.

That would make sense if you were executing code in your head, but if you're reading you want to read all of it anyway...

But @OriginalSyn has a pont. If you are reading code because something is misbehaving on a given configuration and you read

  if (some condition that doesn't hold on that configuration) ...

You can avoid everything inside that if statement if you know that's not important for the case you're considering.

But if we want to avoid it, we would be required to already know what's inside the parenthesis. If we already knew what's inside it, putting condition before helps more as in that case (1) Either it's true and you have to parse the block or (2) It's false and you just jump to the end of it.

Not at all true, most of the time you are reading code with a specific goal or area of interest in mind, and thus are only interested in the subset of code related to that purpose.

yeah I agree here as well, postfix anything is quite annoying to read, especially so when chained, and the absence of parentheses makes this even more terrible

I find it helps when you use short-circuiting. The returns are the first thing you see, making it more obvious what is going on.

  myfn = (arg) ->
    return 1 if arg is "one"
    return 2 if arg is "two"
    return arg.toInt()

This is obviously a little contrived with such a short method, but helps when you have stuff to do between conditional returns.

Yeah. The example is not very good, as it would probably be better to write as switch expression. But on a complex function, returning early can avoid the need to retain a lot of context in your head while reading that code. I find it especially helpful for returning/throwing on error conditions or breaking out of recursion.

I find they are useful for shortcutting out of functions:

    throw 'error' if badness
    
    return null unless goodness

Since it doesn't make sense to return or throw unconditionally it is makes it pretty clear that you should look for the if/unless.

Though, what's the benefit of putting the conditional after? I find these:

    if badness throw 'error'

    unless goodness return null

to be more readable

It's definitely nice to see the return at the beginning of the line -- makes the code easier to scan.

And anytime there's code after a return, it had better be connected to a conditional. :)

Those are good points. I'd probably make it multi-line:

    if badness
      throw 'error'
    
    unless goodness
      return null

If may be strange because of the asymmetry but I'd actually prefer `if` to be come first all the time and `unless` to come last all the time - precisely because `unless` reads like it's for exceptional circumstances:

  value = cache[key]
  if value?
    return value

  return file.readContents() unless not file.exists()

+1 reads poorly

Reply on news.ycombinator.com