Comments on: continue - the forgotten statement http://www.sitepoint.com/blogs/2008/04/14/continue-the-forgotten-statement/ Fri, 25 Jul 2008 05:21:38 +0000 http://wordpress.org/?v=2.5 By: Paul Annesley http://www.sitepoint.com/blogs/2008/04/14/continue-the-forgotten-statement/#comment-696327 Paul Annesley Fri, 18 Apr 2008 00:57:57 +0000 http://www.sitepoint.com/blogs/?p=2423#comment-696327 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. 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.

]]> By: brothercake http://www.sitepoint.com/blogs/2008/04/14/continue-the-forgotten-statement/#comment-693113 brothercake Wed, 16 Apr 2008 01:11:13 +0000 http://www.sitepoint.com/blogs/?p=2423#comment-693113 Well, the difference as I understand it is whether a portion of code is <em>interpreted</em> or merely <em>read through</em> - 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 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

]]> By: borfast http://www.sitepoint.com/blogs/2008/04/14/continue-the-forgotten-statement/#comment-692218 borfast Tue, 15 Apr 2008 10:32:36 +0000 http://www.sitepoint.com/blogs/?p=2423#comment-692218 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. ;) 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. ;)

]]> By: asbjornu http://www.sitepoint.com/blogs/2008/04/14/continue-the-forgotten-statement/#comment-691978 asbjornu Tue, 15 Apr 2008 06:44:30 +0000 http://www.sitepoint.com/blogs/?p=2423#comment-691978 i use the <code>continue</code> statement all the time. In just the same manner, I use <code>return</code> and <code>throw</code> 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 <code>else</code> statements gives you a new execution path to follow and if you nest those three times, the code is three times harder to follow. 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.

]]> By: brothercake http://www.sitepoint.com/blogs/2008/04/14/continue-the-forgotten-statement/#comment-691714 brothercake Tue, 15 Apr 2008 01:17:50 +0000 http://www.sitepoint.com/blogs/?p=2423#comment-691714 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. 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.

]]> By: Dave http://www.sitepoint.com/blogs/2008/04/14/continue-the-forgotten-statement/#comment-691114 Dave Mon, 14 Apr 2008 15:29:08 +0000 http://www.sitepoint.com/blogs/?p=2423#comment-691114 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. 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.

]]> By: Anonymous http://www.sitepoint.com/blogs/2008/04/14/continue-the-forgotten-statement/#comment-691005 Anonymous Mon, 14 Apr 2008 13:54:03 +0000 http://www.sitepoint.com/blogs/?p=2423#comment-691005 Completely agree. Why use structured programming techniques when we can go back to GOTO? </sarcasm> Completely agree. Why use structured programming techniques when we can go back to GOTO? </sarcasm>

]]> By: borfast http://www.sitepoint.com/blogs/2008/04/14/continue-the-forgotten-statement/#comment-690820 borfast Mon, 14 Apr 2008 11:04:35 +0000 http://www.sitepoint.com/blogs/?p=2423#comment-690820 <blockquote>I can’t see how if.. continue.. dostuff is more readable than if... else...</blockquote> It isn't. It's actually less explicit, so one could even argue that it is <em>less</em> 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... :(

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

]]> By: Anonymous http://www.sitepoint.com/blogs/2008/04/14/continue-the-forgotten-statement/#comment-690700 Anonymous Mon, 14 Apr 2008 09:10:08 +0000 http://www.sitepoint.com/blogs/?p=2423#comment-690700 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 <code>if.. continue.. dostuff</code> is more readable than <code>if... else...</code> 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...

]]> By: cranial-bore http://www.sitepoint.com/blogs/2008/04/14/continue-the-forgotten-statement/#comment-690573 cranial-bore Mon, 14 Apr 2008 07:20:19 +0000 http://www.sitepoint.com/blogs/?p=2423#comment-690573 my statement about <em>easier to understand</em> would have been more believable if my line breaks had gone through. my statement about easier to understand would have been more believable if my line breaks had gone through.

]]>