5

In the current software I am working on, I'm seeing this pattern quite extensively and it seems that they're trying to avoid return statements as much as possible. Even at some places in the code this is taken almost to the extreme.

I've somehow heard a long time ago that return statements should be minimized or avoided but I can't remember (or search about) the exact reason or origin of this line of thought. I believe it was due to some performance implication in some PL.

I do not personally adhere to this since it doesn't make code that readable but, giving it the benefit of the doubt, I'm curious whether using this pattern has its merits in javascript in terms of performance.

if (err) {
    if (err.message) {
        message = err.message;
    } else {
        if (err.errorCode) {
            message = err.errorCode;
        } else {
            message = "Unknown error";
        }
    }
} else {
    message = "Unknown error.";
}
deferred.reject(message);

If I were to decide, I'd casually use the return statement to terminate sequence like this:

if(!err || (!err.message && !err.errorCode)){
    deferred.reject("Unknown error.");
    return;
}

if(err.message){
    deferred.reject(err.message);
    return;
}

if(err.errorCode){
    deferred.reject(err.errorCode);
}

Are there advantages in the first pattern over the second one?

john.solano
  • 107
  • 6
  • 1
    A function should do only one thing. `if` condition usually mean your function is doing more than one thing. – Aquila Sagitta Jul 13 '17 at 15:08
  • the problem with using many returns is that it leaves your function at that point, right then and there. Perhaps you have cleanup code, perhaps you have to free objects, perhaps you have to check more things... its is almost always a bad idea to abruptly leave a block of code. – Tuncay Göncüoğlu Jul 13 '17 at 15:44
  • @Andrey You've provided link to another answer on SO, which is nice, but it is `JS`))) and for example, in js you have to return every time you call callback... – cn007b Jul 13 '17 at 15:48
  • @VladimirKovpak I don't think that this is really language related question. This is about early return vs nested conditions. And there is no definite answer, it's just a matter of style/taste/opinion – Andrey Jul 13 '17 at 15:54
  • 2
    The OP was asking about the performance difference between the two, not the coding style. As far as I can tell, there is no significant performance difference. – Kraylog Jul 13 '17 at 15:56

1 Answers1

2

Your code example also have nickname - christmas tree, and in real projects, it is extremely hard support such code.
For example you need add another condition - you will put another if block inside existing and so on and so forth and it is gonna be a nightmare... and as result, you will have an awfull tree...

As alternative, you can something like this:

if (err) {
    if (err.message) {
        return err.message;
    }
    if (err.errorCode) {
        return err.errorCode;
    }
}
return "Unknown error.";

Such code looks simpler, isn't it?
So I truly believe it makes sense use return for such purposes.

BUT, I think that main point here is - don't loose consistency! In our example, we always return a result in same data type and with same business logic, and for example:

if (err) {
    if (err.message) {
        return err;
    }
    // Here some stuff...
    // Few lines of code...
    //
    return -1;
}
// Another code...
//
if (!user) {
    return null;
}
// And somewhere in the end on anothere scrollin screen
//       
return user.email;

this example returns object or number or null or string - and it is another nightmare...
And in real projects in big functions, it is really easy to get such code because of lot returns...
So here better have less count of returns, again because it is easy to support...

cn007b
  • 16,596
  • 7
  • 59
  • 74