TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

Use Proportional Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Samuel Mize <[log in to unmask]>
Fri, 20 Mar 1998 10:02:38 -0600
text/plain (64 lines)

Concerning the loop "continue" statement:

In June of 1997 I put on comp.lang.ada the second draft of a paper
titled "Goto Considered Necessary."  The overall point of the paper
was that gotos are sometimes needed in Ada, and one of the reasons was
loop "continue" logic.

If you want to see the paper, search c.l.a with Deja News, searching
for "goto considered necessary" on Jun 11 1997.  There was significant
follow-up discussion, you can read the thread that this post started.

One point in that paper is: "if your code needs a "goto" to work
efficiently (or at all), you may have overlooked a simpler, better
design."  This includes loop "continue" statements.  Sometimes they're
the best structure, but they can often be designed around.

The paper includes an example of code from Knuth's article about gotos
in the December 1974 Computing Surveys.  Now, this is an excellent
article, and I recommend it.  However, the particular code was cited
as an example of a case where a "continue" is the best, clearest
structure.  It took me maybe 15 minutes to rework it without the
"continue," resulting in a clearer and equally-efficient design.  This
does not prove that "continue"s are always less desireable, but it does
show the benefit of considering them a candidate for re-structuring.

One point that was brought up in the discussion about the paper was
that using a "goto" prevents a common maintenance error.  If some code
must be added to the end of the loop to set up for the next iteration,
a "continue" will skip that code.  With the goto/label approach, there
is a clear place at the end of the loop for any such set-up code.

Here's a much-cut-down version of the paper's summary:

a) In general, "goto" statements should be avoided.

b) As a rule of thumb, if your code needs a "goto" to work efficiently
   (or at all), you may have overlooked a simpler, better design.

c) Exceptions to "goto" avoidance:
   c1) a well-defined code structure that is not supported in the language.
   c2) machine-generated code
   c3) Finite State Machines (FMSs)
   c4) Other usages are suspect, but may be OK.

d) an extraneous state variable or other kludge is no improvement on a "goto".

e) Norm Cohen recommended Knuth's article in the December 1974 Computing
   Surveys as "the best discussion I've ever seen of the goto issue."
   Other respected Ada developers have concurred.

f) The shared Ada culture avoids "goto" statements.

Sam Mize

Samuel Mize -- [log in to unmask] (home email) -- Team Ada
Multi-part MIME message: " ", " ", " " (hands waving)
Fight Spam - see