5 ms·

Two Things About Conditionals in JavaScript

13 points by thisisblurry 14y ago

carstimon 14y ago
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 14y ago
  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.
  - peterhunt 14y ago
    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.
    - untog 14y ago
      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.
  - btilly 14y ago
    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-1995/LoopExits.pdf 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.
    - jrajav 14y ago
      > 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 14y ago
        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?
emef 14y ago
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.
modeless 14y ago
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 14y ago
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 14y ago
  Comments like this make me so excited to write more posts. Thanks.
  - Stratoscope 14y ago
    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.

13 points by thisisblurry 14y ago

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 14y ago
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.
- peterhunt 14y ago
  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.
  - untog 14y ago
    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.
- btilly 14y ago
  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-1995/LoopExits.pdf 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.
  - jrajav 14y ago
    > 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 14y ago
      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?

emef 14y ago

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.

modeless 14y ago

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 14y ago

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 14y ago
Comments like this make me so excited to write more posts. Thanks.
- Stratoscope 14y ago
  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.