Xref: utzoo misc.misc:6036 comp.misc:6016
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!rutgers!att!occrsh!rjd
From: rjd@occrsh.ATT.COM (Randy_Davis)
Newsgroups: misc.misc,comp.misc
Subject: Re: The "evil" GOTO (Was: 25 Years of BASIC)
Summary: BAD example - easy to rewrite without a goto.....
Message-ID: <698@occrsh.ATT.COM>
Date: 8 May 89 15:23:28 GMT
References: <1791@ubu.warwick.UUCP> <1436@onion.reading.ac.uk> <1814@ubu.warwick.UUCP>
Reply-To: rjd@occrsh.UUCP (Randy_Davis)
Followup-To: comp.misc
Organization: AT&T Network & Data Systems, OKC
Lines: 47

In article <1814@ubu.warwick.UUCP> mirk@uk.ac.warwick.cs (Mike Taylor) writes:
[...]
|How many times have you seen this kind of code?
|
|	printf ("Enter your sex: ");
|	while (sex != "m" && sex != "f") {
|		gets (sex);
|		if  (sex != "m" && sex != "f")
|			printf ("<m> or <f> only: ");
|	}
|
|Why make the test twice?  Huh?  Huh?  Answer me that, all you obsessed
|anti-GOTO campaigners.  The *natural* way to express the above is:
|
|	printf ("Enter your sex: ");
|LABEL:	gets (sex);
|	if (sex != "m" && sex != "f") {
|		printf ("<m> or <f> only: ");
|		GOTO LABEL;
|	}
|
|Better examples abound, but in time honoured way, elude me now that I
[...]

  This is the natural way for *me* to express the above example:

	printf ("Enter your sex: ");
	gets(sex);
	while(sex[0] != 'm' && sex[0] != 'f') {
		printf ("<m> or <f> only: ");
		gets(sex);
	}

  Now, admittedly, this is just the answer to *one* example *AND* it duplicates
one instruction (the gets) and thus makes the program incrementally larger.
YET, I have yet to see a GOTO program that could not have easily been written
without it....  Not neccessarily faster or more efficiently mind you - *I* am
not a "rabid anti-GOTOer", yet they rarely add to the readability of the
program, not that that is always an important attribute.

   It just seems to me to be the mark of a lazy programmer that doesn't take
the time to think of a way around the GOTO.  If he does know the way around
it and does it for a more efficient or more compact program, though - that's
another story.

Randy Davis					UUCP: ...(att!)ocrjd!randy
						      ...(att!)occrsh!rjd