In the book Javascript: The Good Parts by Douglas Crockford, this is all the author has to say about the continue Statement:
The
continue
statement jumps to the top of the loop. I have never seen a piece of code that was not improved by refactoring it to remove thecontinue
statement.
This really confuses me. I know Crockford has some very opinionated views on JavaScript, but this just sounds entirely wrong to me.
First of all, continue
does more than just jump to the top of a loop. By default, it also progresses to the next iteration. So isn't Crockford's statement just completely false information?
More importantly, I do not entirely understand why continue
would even be considered to be bad. This post provides what seems to be the general assumption: Why is continue inside a loop a bad idea?
Although I understand how continue
may make code difficult to read in certain instances, I think it is just as likely that it can make code more readable. For instance:
var someArray=['blah',5,'stuff',7]; for(var i=0;i<someArray.length;i++){ if(typeof someArray[i]==='number'){ for(var j=0;j<someArray[i];j++){ console.log(j); } } }
This could be refactored into:
var someArray=['blah',5,'stuff',7]; for(var i=0;i<someArray.length;i++){ if(typeof someArray[i]!=='number'){ continue; } for(var j=0;j<someArray[i];j++){ console.log(j); } }
continue
isn't particularly beneficial in this specific example, but it does demonstrate the fact that it reduces the nesting depth. In more complex code, this could potentially increase readability.
Crockford provides no explanation as to why continue
should not be used, so is there some deeper significance behind this opinion that I am missing?
break and continue are not functional style programming. There is nothing about OOP which suggests break , continue or even goto within a method is a bad idea.
That is, if you believe using “continue” is wrong, logically our argument must also forbid the use of using a “return” statement anywhere other than as the last statement of a function. They both prematurely interrupt the flow of execution for a particular block of code.
The continue statement breaks one iteration (in the loop) if a specified condition occurs, and continues with the next iteration in the loop. The difference between continue and the break statement, is instead of "jumping out" of a loop, the continue statement "jumps over" one iteration in the loop.
The continue statement in C programming works somewhat like the break statement. Instead of forcing termination, it forces the next iteration of the loop to take place, skipping any code in between. For the for loop, continue statement causes the conditional test and increment portions of the loop to execute.
The statement is ridiculous. continue
can be abused, but it often helps readability.
Typical use:
for (somecondition) { if (!firsttest) continue; some_provisional_work_that_is_almost_always_needed(); if (!further_tests()) continue; do_expensive_operation(); }
The goal is to avoid 'lasagna' code, where you have deeply nested conditionals.
Edited to add:
Yes, this is ultimately subjective. Here's my metric for deciding.
Edited one last time:
This example is too simple, of course, and you can always replace nested conditionals with function calls. But then you may have to pass data into the nested functions by reference, which can create refactoring problems at least as bad as the ones you're trying to avoid.
I am personally on the other side than the majority here. The problem is usually not with the shown continue
patterns, but with more deeply nested ones, where possible code paths may become hard to see.
But even your example with one continue
does not show improvement in my opinion that is justifiable. From my experience a few continue
statements are a nightmare to refactor later (even for static languages better suited for automated refactoring like Java, especially when someone later puts there break
too).
Thus, I would add a comment to the quote you gave:
Refactoring to remove
continue
statement inreases your further ability to refactor.
And inner loops are really good candidated for e.g. extract function. Such refactoring is done when the inner loop becomes complex and then continue
may make it painful.
These are my honest opinions after working professionally on JavaScript projects in a team, there rules that Douglas Crockford talks about really show their merits.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With