Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site 3comvax.UUCP
Path: utzoo!linus!decvax!decwrl!Glacier!oliveb!3comvax!mikes
From: mikes@3comvax.UUCP (Mike Shannon)
Newsgroups: net.lang.c
Subject: Re: break, continue, return, goto
Message-ID: <267@3comvax.UUCP>
Date: Mon, 4-Nov-85 18:07:22 EST
Article-I.D.: 3comvax.267
Posted: Mon Nov  4 18:07:22 1985
Date-Received: Fri, 8-Nov-85 05:05:12 EST
References: <771@whuxl.UUCP>
Distribution: net
Organization: 3Com Corp; Mountain View, CA
Lines: 24

In the cited article, Michael Baldwin write
> This is in response to those who think that break, continue, and
> multiple returns are bad things.  As with anything, they can be
> abused, but I find continue and multiple returns extremely useful
> for dealing with errors, and break for ending complicated search loops.
>.......

	And I think he has really addressed the critical issue.  The important
thing is that the code we write clearly show our intention.  If you 
*think* about a problem in a certain way, your code should reflect it.
This link between syntax and intention makes programs more reliable,
easier to read, and cheaper to maintain.
	If your code looks 'goto'-ey, you probably should attack your
programming problem from a different perspective.  Think about the
problem in a new way.
	I think that multiple return and break statements are fine to deal
with unexpected error conditions.  In this context, boolean loop-termination
variables might obscure the author's intention.
	But when the programmer has a complete choice of data structures
and program structure, it's another story.  All too often, multiple
returns and break statements reflect either a lack of exposure to data
structures or fuzzy thinking about the problem which needs to be solved.
-- 
			Michael Shannon {ihnp4,hplabs}!oliveb!3comvax!mikes