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