Avoid Else, Return Early (2013)

Re:Avoid Else, Return Early (2013) by arghwhat on Monday March 26, 2018 @09:09AM (#16678545)

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.

[ Parent | on HN ]

Re:Avoid Else, Return Early (2013) by foobarchu on Monday March 26, 2018 @09:19AM (#16678616)

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.

[ Parent | on HN ]

Re:Avoid Else, Return Early (2013) by arghwhat on Monday March 26, 2018 @09:50AM (#16678833)

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.

[ Parent | on HN ]

Re:Avoid Else, Return Early (2013) by jehlakj on Monday March 26, 2018 @10:45AM (#16679250)

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.

[ Parent | on HN ]

Re:Avoid Else, Return Early (2013) by olavk on Monday March 26, 2018 @12:09PM (#16679912)

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.

[ Parent | on HN ]

Re:Avoid Else, Return Early (2013) by arghwhat on Tuesday March 27, 2018 @05:08AM (#16686607)

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.

[ Parent | on HN ]