Two Things About Conditionals in JavaScript | Hacker News Reader

Two Things About Conditionals in JavaScript

rmurphey.com

13 pointsthisisblurry12 comments

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').

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.

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

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.

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.

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).

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.

I don't dispute that your argument has merit, but I disagree. An early exit from a function is an instance of "flat is better than nested" -- that is, it's often easier on the brain to not have to keep track of different layers of nesting. I often use early exits just to get rid off edge cases so the rest of my (non-nested) function can just deal with the "normal" case.

Absolutely agree.

    if (a == null) return false;
    stuff();

is considerably better than

    if (a != null) {
        stuff();
    }

Especially once you start dealing with a ton of these cases.

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-... 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.

> 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.

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?

Reply on news.ycombinator.com