

Two Things About Conditionals in JavaScript - thisisblurry
http://rmurphey.com/blog/2012/12/10/js-conditionals/

======
modeless
The last refactoring is not equivalent to the previous versions. The behavior
of the function is changed when it is passed a non-number like an object
reference or NaN (before it would return undefined; after it returns 'big').

------
Stratoscope
Poor article with poor code, and poor responses from the author in the
article's own comments. The comment from 'isaacs' is better thought out than
the article itself.

As isaacs points out, the first part of the article about "else if" is much
ado about very little. And why the sideways hint that there is something wrong
with "else if"?

The second part is lazy and inconsistent refactoring. Why go through the
exercise of removing the <= 100 test and never notice that there's also a
redundant <= 10 test in all three examples?

If you know JavaScript at all, this article is a waste of your time.

~~~
rmurphey3
Comments like this make me so excited to write more posts. Thanks.

~~~
Stratoscope
I forgot to add: Poor HN comment by Stratoscope.

I'm sorry, Rebecca, I should have found a much more polite and constructive
way to phrase my comment. Please forgive me for my bad attitude yesterday.

Perhaps I could get back to you with some more positive and specific
suggestions on how the article could be improved? In the meantime I just
wanted to apologize for the tone of my comment.

------
emef
I'd argue that it's a bad practice to leave out the last else if condition
even when it seems redundant. What happens if NaN is passed to your function?
It will return 'big' when you probably want to throw an exception or something
more meaningful.

------
carstimon
Under the if/else: I kind of prefer the first code sample, then the second,
then the third. The first emphasizes to the reader the structure of the
function. With one look you can see the function is choosing from three
options.

For example, if the insides of the if statements were a touch more
complicated, the third could also fit the pattern of a recursive function with
two base cases. We would have to read more to figure out the idea.

The first is preferable to the second because I immediately see that only one
thing will happen, I don't need to look inside the if's. (Relevant if the
inside is more complicated).

~~~
jrajav
Agreed (assuming you meant point #2). Having multiple returns in a function is
a huge code smell to me. It looks great at this size, but can get unwieldy
very fast. The second half of this article looks like a typical refactor cycle
for me - but in reverse.

As for exactly why: Having multiple returns means multiple points of exit from
a function, which complicates the flow of control and requires you to follow
more paths backwards to find state changes and final values. In general it is
easiest to read and most maintainable to have a function flow from top to
bottom.

~~~
btilly
What you have stated is an article of faith from the structured programming
movement back in the 1970s. There should be one and only one exit from a
function or loop. However this is an article of faith that does not tend to be
backed up with any concrete evidence that it is right - just unsupported
assertions.

By contrast [http://www-cs-
faculty.stanford.edu/~eroberts//papers/SIGCSE-...](http://www-cs-
faculty.stanford.edu/~eroberts//papers/SIGCSE-1995/LoopExits.pdf) from 1995
does a very good job of arguing the opposite side of that. Not simply as an
article of faith - but with actual data showing that internal loop and
function exits make correct programming easier and more efficient. There are
common problems that are significantly easier both for novices and experts to
get right if you allow internal loop exits, and potentially multiple returns.
(In particular the "loop and a half" problem.)

That doesn't mean that you should go crazy with the construct. You should be
particularly careful with long functions (long functions are their own code
smell). However judicious use of it is most certainly justifiable.

~~~
jrajav
> What you have stated is an article of faith from the structured programming
> movement back in the 1970s. There should be one and only one exit from a
> function or loop. However this is an article of faith that does not tend to
> be backed up with any concrete evidence that it is right - just unsupported
> assertions.

This is a little overboard, considering that I did offer support for my
assertions: My own personal experience, and sound explanation. I have had to
maintain code heavy with returns, and not of the sane, early-exit kind
mentioned by peterhunt - deeply nested returns based on obscure logic. I
didn't even know before now that there was any such "movement" around this
particular opinion, however long ago, I just know that it makes sense for me
and will always appear in my style guidelines.

And yes, it would be much better to finely modularize your code in the first
place so that low level flow-control guidelines like this become trivial, but
that's not always practical on a large team with programmers of varying skill.

~~~
btilly
Your "support" was a bare opinion about what kind of flow of control is
easiest to read. To me that is just a restatement of your opinion and not
support.

By contrast in two responses, two different flows of control were presented
where early exits make for more readable code. (Guard conditions and the loop-
and-a-half problem.) Furthermore my personal experience disagrees with you, as
does the reasoning of a fairly well thought out article that I referred you
to. Which also presented pointers to research indicating that it is easier for
students to produce correct code for some common problems if they have the
possibility of correct code. Granted, students are generally less competent
than professional programmers. However if you're concerned about varying skill
on your team, why would you choose to make it harder for the poorer
programmers to correctly solve problems?

Out of curiosity, what would it take for you to reconsider your style guides?

