Discussion on: I've never become overly convinced that switch statements are that much cleaner than `if else if else if else if else`

View post

Replies for: If you're returning then you don't even need the else. if (x === 'a') { return 1; } if (x === 'b') { return 2; } Enter fullscreen mo...

Andrew Harpin • Jun 28 '19

Depends on the language, but for safety critical code, multiple function exits are typically frowned upon.

Peter Harrison • Jun 28 '19

Nah. Exit early. Makes the code cleaner and clearer.

Scott Yeatts • Jun 29 '19

Gotta respectfully throw out a dispute. I've heard this statement used to justify multiple returns before... Looks like

if (x) {
    return a + x
} else if (y) {
    return a + y
} else {
    return a
}

With the justification that it avoids evaluating the additional conditionals if the first proves true.

I just don't think the performance loss is there barring some REALLY funky conditionals or some other code smell...

This is a rule that feels like it came from the old C days and just stuck around past it's expiration date, because that same logic, but expressed as

if (x) {
    a = a + x;
} else if (y) {
    a = a + y;
}

return a;

Is so much more readable and you can look at one line to know what's going to be returned, then you only have to debug/watch one thing, and it's just SO much cleaner... If I run into a problem with evaluating conditionals to get syntax that clean, then I feel like something else is wrong in the code... It's also more bug resistant and ensures that the method is doing ONE thing. Less chance that someone can come along and decide to start returning Strings instead of ints in one of the return statements or something wacky like that...

Peter Harrison • Jul 1 '19

In the real situations I encounter the issue is that having early returns means being able to avoid huge indents. When reading code where the return is at the bottom of a long complex structure you are forced to parse the entire function to ensure there is no subsequent operation which influences the return value. Having one return value generally means having the return variable declaration at the highest level, and so it could potentially be modified through the function. You might intend for it not to be modified once set, but a later modification might overwrite it. A early return is syntactically a succinct expression of the intent. We are finished. Return this value now. I know that in the early days of programming there was a good reason not to return early, especially in the middle of a loop. Don't think there is any issue at all with this any more.

Scott Yeatts • Jul 1 '19

I could easily see if I'm dealing with a returnable statement over 20 lines where the return value is based on multiple conditionals or is impossible to keep in your head all at once, that return early and often would be a good backstop to make sure you know what is returned and when... And I HAVE run into code like this in the wild that I couldn't refactor entirely for stability, but I could make sure it was readable, and that did involve applying Exit Early.

With new code or things I could refactor, I would have to go with Uncle Bob's rule from Clean Code

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. Functions should not be 100 lines long. Functions should hardly ever be 20 lines long.

If you're dealing with multiple nested conditionals or the triangle of death where nesting is making the indents move out and out until your code looks like an arrow pointing off to the right, then the function is probably just too big and needs to be broken up for maintainability...

But now we're going to get so far off the topic we'll need to write a whole new topic to keep this up hahaha!

Peter Harrison • Jul 1 '19

I broadly agree with the idea that functions should be small, but care should be taken not to break up logically sequential operations that really belong together just to comply with this principle.

More important to me is that a function should have one clearly defined purpose and not mash together a bunch of logically separate operations.

Switches tend to be used for doing multiple separate things based on some value. It is not always bad, but I always evaluate whether there is a better more extensible way to do it than a switch when I see it.

I'm not saying I've never used a switch, but it is generally not one I use unless there is a really good reason.