Continue without Me!
In similar situations, with code like the loop just shown, the continue keyword can be used to skip over blocks of code and jump back to the condition check in the loop. Isn't this just as bad as using a goto statement that jumps to the beginning of a set of statements? Again, with properly structured code and condition checks, continue can usually be avoided.
To make matters worse, I've seen continue coupled with labels (which, in the case of Java, can be done with break as well). Note the following as an example (which works with break as well):
public boolean someMethod(String[] data1, String[] data2) {
loop_one: for ( int i = 0; i < data1.length; i++ )
{
loop_two: for ( int x = 0; x < data2.length; x++ )
{
// Some useful code here...
if ( data2[x] == null )
continue loop_one;
}
}
}
In this case, the programmer is effectively using the goto statement, as the code jumps to a specific location other than where the natural code flow would bring it. Although for performance reasons, I can see cases to use continue, I cannot find a reasonable case for labels in conjunction.
Conclusion
Although my style is to avoid mid-method returns, excessive break statements, most uses of the continue statement, and all uses of labels, these are only personal guidelines. I find it rarely makes sense to be so rigid about things, as situations do arise that justify breaking the "rules" from time to time. This is why I suggest referring to them as "guidelines" instead.
The next time you put together a set of programming standards, guidelines, or a style guide, I suggest you not include "don't use goto." Instead, be more clear, concise, and thorough, and state, "don't use code constructs that disrupt the natural execution flow, readability, and modifiability of your code via the use of needless mid-method returns, labeled break and continue statements, and the goto keyword." After all, readability, maintainability, and robustness are the underlying goals when we put together guidelines.
