continue – the forgotten statement

Tweet

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.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://www.deanclatworthy.com Dean C

    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.

  • http://www.mikehealy.com.au cranial-bore

    I like continue to reduce indentation and lines.
    By saving an else{} block in the loop the code is easier to understand.

    
    for(loop)
    {
       if(!relevant_now) continue;
    
       do stuff
    }
    
  • http://www.mikehealy.com.au cranial-bore

    my statement about easier to understand would have been more believable if my line breaks had gone through.

  • Anonymous

    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.. dostuff is more readable than if... else...

  • borfast

    I can’t see how if.. continue.. dostuff is more readable than if… else…

    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… :(

  • Anonymous

    Completely agree. Why use structured programming techniques when we can go back to GOTO? </sarcasm>

  • Dave

    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.

  • http://www.brothercake.com/ brothercake

    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.

  • asbjornu

    i use the continue statement all the time. In just the same manner, I use return and throw statements 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 else statements gives you a new execution path to follow and if you nest those three times, the code is three times harder to follow.

  • http://www.borfast.com borfast

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

  • http://www.brothercake.com/ brothercake

    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

  • Paul Annesley

    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.