C++ is not Ocaml, and Mozilla is not random-opensource-project. When you're contributing to an established project, you follow the conventions there even if they aren't what you'd consider ideal.<p>Brendan Eich even said as much in the comments of the bug: he'd rather be programming in a pure, expression-based manner too, but C++ is not Ocaml. And for a lot of C++ code, no-else-after-return works reasonably well.
I'm with Mozilla.<p>If I have a function with multiple conditions that cause me to return error / false / nil, I'd rather not have to nest them all in a series of if/then/else statements nor combine them into a single more-complicated if condition. I'd rather write them each as separate if-and-returns, followed by the real meat of the function.<p>function updatePlayers{<p><pre><code> if (charList is empty)
return false;
if (play is paused)
return false;
if (char is frozen)
return false;
//do stuff here
return true;</code></pre>
}<p>I think this better spells out the "error" conditions.
I always go a step further, and use at most one "return" in a function.<p>I find short-cut "return" statements frustrating for many reasons. For example, there's a risk that proper cleanup will not always happen, it is harder to see state and program flow when debugging, and it's no longer simple to make every-case changes by adding things to the end of the function. They're really just another type of "goto".<p>The only "advantages" I can think of are saving a few keystrokes, and having slightly better performance by not using a variable for the return value. In my experience, neither of those things has ever mattered.<p>In other words, I'd do this:<p><pre><code> <type> result = defaultValue;
if (condition)
{
result = val1;
}
else
{
result = val2;
}
return result;
</code></pre>
With this approach, there is never anything after the "return", "else" or otherwise.
A minor quibble. He claims that "no-elses" are prone to side-effects and "error-prone junk". However, "no-elses" are in my opinion as flagrant a crime as "no-braces" following if statements (which appears to be his style). The author says that he prefers the <i>ternary</i> operator (a > b ? a : b) to "no-elses"; however, its use is definitely more error-prone!
I prefer to return as early as possible and I dislike unnecessary else clauses. And unnecessary braces. I especially hate really long functions where there's only one return but a bunch of baggage and nested conditionals along the way to pull it off. Like mullr said, only handy if your language doesn't support guards.<p>Most of the people who code this way that I've met don't do it b/c they're trying to be 'pure.' Most of them say it was coding standard some manager mentioned somewhere else long ago and now they just do it w/o thinking.
On the one hand, this reads like "I prefer functional languages, and want to twist procedural languages into a form I'm more familiar with". On the other hand, I do find his re-written example more readable, and I'm not sure if that's due to my previous exposure to functional programming, some innate readability bestowed by the functional programming style, or just the fact that this particular code was rewritten by someone who wanted to make it a publishable example (as opposed to just getting it to work).
What's his argument about purity here? His examples rely on global state which is inherently impure. Rewriting them to make it more expression like does nothing to change that.
I think the main problem is the lack of braces means you have to rely on white space to figure out what the hell is going on.<p>That's the main reason why I religiously put open and close braces on even the smallest if/else blocks as it dramatically improves the readability of the code.<p>If the mozilla code style specified that you have to use braces no matter what then they wouldn't be having this problem.<p>Of course, I'm probably arguing with hackers who prefer to use constructs like 'return (a > b ? a : b)' rather than write readable code.<p>This is coming from someone who likes to put spaces after and before parentheses so it makes it easier to figure out what's going on.<p>e.g. if ( ( y > x ) || ( x < 10 ) ) - this makes things easier to read (for me) when you start to get a hell of a lot of nesting going.
And here we have a classical bikeshedding article.<p>This sort of thing really doesn't matter much one way or another. Do what the rest of the codebase is doing, and move on with your life. If you're writing your own code, do what you feel like doing.
I disagree. The rule works for me.<p>I now find myself using 'cond' almost exclusively over 'if'.<p>And there is a little misunderstanding propagated: "Even in a language like C/C++ you can do something approaching functional programming by avoiding statements". I don't think so.