Hacker News Reader

Comment by olavk | Hacker News Reader

I am arguing this is worse, since it expresses the logic in a more convoluted way.

I would argue that it is by no means more convoluted. It is quite clear and concise. All of the following are equally readable:

    if (x > y) {
        return x;
    } else {
        return y;
    }

    if (x > y) {
        return x;
    }
    return y;

    return (x > y) ? x : y;

The logic would be convoluted if you are going through extra hoops in order to write your logic like this, making the flow of the application unclear. For some things, an else branch ends up just being easier to deal with. This is especially true in languages like Rust, where if/else is an expression, leading to the following construct being used often (although usually with more complicated content):

    let max = if (x > y) {
        x
    } else {
        y
    };

Note that "max" is immutable despite the conditional assignment due to the if being used as an expression.

I think it's only clear and concise looking because of the achilles heel of this entire thread: terse examples. As soon as you need to do more than a single line of work, the else'd version becomes far more readable (due to superior indentation and clearer guarantees of what happens when).

If it's a single line of return in both branches, then a ternary expression is usually going to be ideal instead.

We can definitely agree that the examples are too simple to present any readability issues with any method of writing them short of an IOCCC entry.

I do not agree with the conclusions you draw at all, but it is hard to continue the discussion without examples. There are definitely cases where an else clause is the natural choice, but I believe that these are in the minority.

If you’ve ever had to deal with various errors or to filter out something and return the appropriate output, it is much more concise. Read past the if’s and you have the main logic of that function.

But that max function should have an else statement since it's part of the logic. Less code doesn't always make it more concise. If there's a more complicated logic, then it'd actually be harder to understand at a glance.

The examples are only similar to the extent that they do the same. If you look at what intent they communicate - which is an important part of readability - the second example indicates that x>y is a "special case", which just obscures the simple logic of the function.

I agree that what they communicate is important, but I disagree that the early return communicates "x>y" as a special case.

Nothing about early return indicates a special case, but rather just indicate that a conclusion has been reached. A few examples:

    1. A function that compares two arrays, and first checks if they are null or if their lengths differ before checking their individual elements, and potentially recursing. The early returns are likely to be the hottest section of the function, with the element checking being the special case.
    2. A function that searches a list or tree for a node that matches a set of conditions. All but at most one run will use the early returns, making the corpus of the function the special case.
    3. A function that does some processing, with fast paths that handle the vast majority of data, but a slow path for when the fast paths do not apply. The fast path is an early return, but the slow path is the special case.

In other words, I believe that it is incorrect to consider an early return to be a special-case, and interpreting code like so might result in misunderstandings. You should look at the condition to see if it is a special case. The only thing an early return indicate is that the return value has been decided, and no further processing is needed.

I still think that all my examples communicate the exact same to the reader.

I guess I would politely argue that creating new functions would make reading code harder in basic example such are this. You'll be jumping all round or possibly separate files. Obviously larger logic tress should be pruned. Side note: a lambda function may get around this specific instance.

The simple cases do come up though. I've written plenty of functions which amount to little more than a single if-statement and I have had people ask me to make changes like

  foo(things) {
      stuff = do_work(things);

      if (stuff) {
          return a;
      } else {
          return b;
      }
  }

into

  foo(things) {
      stuff = do_work(things);

      if (stuff) {
          return a;
      }

      return b;
   }

in code reviews.

>I am arguing this is worse, since it expresses the logic in a more convoluted way.

Ok, I really wonder if in this special case the logic just looks _odd_ because of bracing styles. (bear with me)

This is very easy to understand, where as the parent example, not as much.

  fun max(a, b)
  {
    if a > b
    {
      return a
    }
    return b
  }

Regardless of bracing style, I still interpret `return a` as a special case with respect to control flow due to the indentation. `return b`, on the other hand, is on the "happy path" — if this wasn't simply a max function, I'd assume from the indentation that it'd return `b` most of the time.

A max function is one of those rare moments where a ternary statement just seems right, but it's an admittedly simple example.

>I still interpret `return a` as a special case...

I think this is interesting. I wonder if our personal experiences with how we learned programming, maybe first languages or first teachers or jobs, etc... would effect our perceptions on logic flow.

I simple don't see anything unusual about the logic flow in the example. It's a simple if/else - return with less cruft to me.

Possible, and also shaped with recent language experiences. My first languages were JavaScript and C++ pretty much simultaneously. In both I'd write a max function with a ternary operator. It signals to me — in the same way as if/else — that no outcome is expected to be more usual or typical than the other, and that no path is more notable or interesting that the other.

The control flow isn't confusing either way, and some language linters will insist against if/else in this example, but I see the if/else approach with slightly more clarity. In general, though, I'm a big proponent of early return.

Reply on news.ycombinator.com