I’m a big fan of continue, partly just because it’s a positive and encouraging word (carry on, everything’s fine
), but mostly because it can reduce code and improve efficiency, and that’s almost always a good thing.
Here’s a quick precis: the continue statement can be used within an iterator, such as a for loop, and means continue to the next iteration
; this is contrast to the break statement which means abandon this loop entirely
.
So, whenever the code inside an iterator is finished for that iteration, we can use the continue statemtent to prevent the interpretor from reading unecessary code, and to reduce the actual amount of code we have to type.
For example, this code:
for(var i=0; i<ary.length; i++)
{
if(ary[i] == 'foo')
{
//something
}
else
{
//whatever
}
}Could also be written like this:
for(var i=0; i<ary.length; i++)
{
if(ary[i] == 'foo')
{
//something
continue;
}
//whatever
}
I’m also a big fan of continue as a means to jump past conditions we’re never interested in, such as ignoring external prototypes when iterating through the properties of an object; so rather than this:
for(var i in obj)
{
if(obj.hasOwnProperty(i))
{
//whatever
}
}We can do this:
for(var i in obj)
{
if(!obj.hasOwnProperty(i)) { continue; }
//whatever
}
So what’s the real difference? Well, we’ve avoided the need for a braced condition, which can make the code more efficient (since the interpretor doesn’t have to evaluate that condition), and I think it also makes the code easier to read — every level of bracing introduces an extra piece of cognitive load, and reducing them is desirable simply for that reason. The continue statement is a means of avoiding such conditions in iterative code, and that’s why I like them so much.
If you liked this blog, share the love:
April 14th, 2008 at 5:08 pm
If there are conditions you’re not interested in, why even define them? I can’t even remember the last time I used continue. If you define your statements well enough, I can’t see the point.
April 14th, 2008 at 5:19 pm
I like continue to reduce indentation and lines.
By saving an else{} block in the loop the code is easier to understand.
April 14th, 2008 at 5:20 pm
my statement about easier to understand would have been more believable if my line breaks had gone through.
April 14th, 2008 at 7:10 pm
I rarely use the continue keyword. Not because I’ve forgotten about it, but because I choose not to use it. I think Javascript programmers are often too interested in writing ‘clever’ shortcuts than writing clean maintainable code.
When compressed the second example will actually be larger than the first and, arguably, less readable. cranial-bore, I can’t see how
if.. continue.. dostuffis more readable thanif... else...April 14th, 2008 at 9:04 pm
It isn’t. It’s actually less explicit, so one could even argue that it is less readable.
As for the code efficiency argument also in the second example, I may be wrong but I don’t think it applies, because if the if() condition is false, the code will not be interpreted anyway.
I don’t mean to be offensive or look like I just want to bash the author but honestly, this article looks a little useless and written in a hurry without any care, just to say that something was published… :(
April 14th, 2008 at 11:54 pm
Completely agree. Why use structured programming techniques when we can go back to GOTO? </sarcasm>
April 15th, 2008 at 1:29 am
More efficient? No Exactly the same. You still have to evaluate the conditional, and the same ’so stuff’ and/or ‘whatever’ code gets run with both styles. Also, repeat after me: Premature Optimisation Is Bad.
The only reason to use it is readability. I would argue that it is less readable than a single if/else, but that multiple continues are more readable than nested if/else’s - other people may disagree.
Not a great article.
April 15th, 2008 at 11:17 am
Okay so I ran a benchmark against these two patterns, and the continue pattern is faster every time (over 10 millions iterations); it’s not massively faster, but the difference is there and predictable.
That wasn’t really my main point anyway - I like the continue pattern because I just think it reads better; maybe that’s just my aesthetic, but it works for me :)
ps - this is not an article, it’s a blog post; of course I knocked it off quickly, it’s a blog post.
April 15th, 2008 at 4:44 pm
i use the
continuestatement all the time. In just the same manner, I usereturnandthrowstatements too; all in the upper parts of the function/method/loop body to get rid of all erronous states first. This makes for a lot cleaner code in my opinion, especially since it gives a lot less indentation and nesting levels.All those
elsestatements gives you a new execution path to follow and if you nest those three times, the code is three times harder to follow.April 15th, 2008 at 8:32 pm
brothercake, sorry, I did not notice this was a blog post; since it looks the same as the rest of the sitepoint website and I landed here directly from another site, I did not notice it wasn’t a full article. I take back what I said about this, then :)
As for the continue being faster, I still don’t think it makes sense. I’m not ignoring the facts (your benchmarks) but as Dave said, the conditional is still evaluated, so it really shouldn’t make any difference.
Could you post the code you used for your benchmark? I think it would be interesting to try to figure out why it was faster - perhaps we can extrapolate and learn a new way to make our code faster in other bits, too. ;)
April 16th, 2008 at 11:11 am
Well, the difference as I understand it is whether a portion of code is interpreted or merely read through - the else{} portion always needs to be read through, looking for where it ends, but it doesn’t need to be interpreted unless the if() case is false.
Course I might be completely wrong.
Here’s the benchmark: http://www.brothercake.com/clients/sitepoint/benchmarks.html
April 18th, 2008 at 10:57 am
cranial-bore: I’ve fixed your code formatting.
There’s a little item in the right hand column here called ‘Posting Code Snippets - Marking Up Your Code’ which is handy to refer to.