Path: utzoo!attcan!uunet!zephyr.ens.tek.com!tektronix!psueea!psueea.uucp!kirkenda
From: kirkenda@psueea.uucp (Steve Kirkendall)
Newsgroups: comp.os.minix
Subject: Re: gotos
Message-ID: <1764@psueea.UUCP>
Date: 2 Oct 89 01:51:01 GMT
References: <24962@louie.udel.EDU> <1989Sep29.183703.1275@utzoo.uucp>
Sender: news@psueea.UUCP
Reply-To: kirkenda@jove.cs.pdx.edu (Steve Kirkendall)
Organization: Dept. of Computer Science, Portland State University; Portland OR
Lines: 25

In article <1989Sep29.183703.1275@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <24962@louie.udel.EDU> tweten@gilmore.nas.nasa.gov (Dave Tweten) writes:
>>surely an absolute "No gotos" is not a defensable position.
>
>I'd say it is, actually.  I haven't used one in years.  My experience is
>that the temptation to use a goto is a sign that the code is poorly thought
>out; the proper response (barring emergencies) is to rethink it.  Oddly
>enough, when I do, the goto *invariably* goes away.

I use gotos about 5 times a year, writing application programs.  Mostly I use
them to break out of two or more levels of looping.  My favorite label names
are "BreakBreak" and "ContContCont".

I can't remember the last time I used a goto as anything except a multi-level
"break" or "continue" instruction.

But I won't let *anybody* tell me I'm wrong to use "goto BreakBreak" to break
out of embedded loops.  Some gotos *are* structured.

(BTW, the code that AST complained about was *not* this kind of goto.  It was
the spagetti kind.  Complaint about that goto was justified;  I only disagree
with the blanket "No Gotos" rule.)
	-- Steve Kirkendall
	      ...uunet!tektronix!psueea!jove!kirkenda
	or    kirkenda@cs.pdx.edu