Channels ▼


Programming with Reason: Why is goto Bad?

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.


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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.