Is an argument to break, continue a bad idea?

[Chris Torek]

In article <1990May1.165701.4289 at utzoo.uucp> henry at utzoo.uucp
(Henry Spencer) writes:
>Why use loops, or ifs, or any other control structures, which replace some
>subset of the functionality of the goto?  Because they are easier to read
>and harder to make mistakes with. ... The constraint [that break and
>continue impose on code reachability] is important, indeed crucial;
>without it, one might as well use goto.

This is the heart of the matter.  Like power tools, powerful constructs
should always be avaliable; like power tools, powerful constructs should
not be the workman's only choice.  One does not use a table saw to cut
a small notch in a small piece of wood.

In its rawest form (which, in C, is actually represented as longjmp,
not as the keyword `goto'), `goto' is the most powerful control
construct that exists.  *All* other control constructs, including
`return', are simply restricted forms of `go to'.  The restrictions
exist precisely because the result is easier for programmers (and, to a
limited extent, for compilers) to handle.

If you intend for your code to be readable and maintainable, you should
find the least powerful constructs that solve the problems you need
solved in the most straightforward manner available.  (This leaves a
great deal of room for dispute as to what is straightforward.  This is
as it should be.  It also says nothing about external constraints,
efficiency and expediency being primary examples.  This, too, is as it
should be---general principles have to be simple and neat, and ignore
the Real World.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris