from Hacker News

Two Things About Conditionals in JavaScript

by thisisblurry on 12/11/12, 2:36 AM with 12 comments

• by modeless on 12/11/12, 3:25 AM

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

• by Stratoscope on 12/11/12, 4:21 AM

  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.

• by emef on 12/11/12, 3:16 AM

  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.

• by carstimon on 12/11/12, 3:03 AM

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