Hi All!

Some use of GOTOs is permissible for special situations. However, as a rule, you ought never use this construct because IT DOES weaken or destroy adherence to the structured programming concept.

Sure, if the ultimate result is the same, it may be easy to dismiss this "dogma" as bunk. However, when dealing with complex code you are betting your job on your ability to find bugs following (YES!) your convoluted logic promoted by your GOTO code. At least trying to stay away from it imposes a structure (input, process, output) as opposed to a free-for-all (input, input, output, process, output, etc).

If I see one too many GOTOs in anyone's code, I consider them suspect unless they can explain the need for these.

I could not resist.

John

>From: "Paul M. Dorfman" <sashole@EARTHLINK.NET> >Reply-To: "Paul M. Dorfman" <sashole@EARTHLINK.NET> >To: SAS-L@UGA.CC.UGA.EDU >Subject: Re: Programming Theory Question. >Date: Fri, 11 Jun 1999 12:31:17 -0400 > >Rich, > >It could not have been said better. Cracking down on GOTOs to prevent >'unstructured' programming has the same nature as eliminating guns: It >shifts >the culpability from one who misuses a tool onto the tool itself. > >Many spears have been broken over this one. We can discuss it here forever >without revealing any new truths. Anti-GOTO hysteria has been around for >years >spearheaded by COBOL 'shops standard legislators' trained in 'structured >programming'. For curiosity sake, I have surveyed two dozen or so COBOL >guys >asking just one question: What IS structured programming? NOBODY had a >clear >idea, the most common notion having been 'programming without GOTOs'. > >GOTOless mindset is just a dogma, a form of religion based solely on faith. >In >his response to the original question, Paul Thompson's wrote: > >"There is always a better way than a GOTO. >HEre is some FLAMEBAIT: >THERE IS NEVER A NEED FOR A GOTO. NEVER." > >This is expressed in the form of a mathematical theorem. Any mathematical >theorem (in particular, expressed in terms of ALWAYS and NEVER) is >considered >disproved if a single counterexample can be found. In this case, there are >many. >One of the worst myths about GOTOs is that anything written using them can >be >rewritten without ones leaving efficiency intact. Those who think it is >true >might want to read through Donald E. Knuth's brilliant article 'Structured >Programming With GO TO Statements' published as part of the book 'Literate >Programming'. If, after reading the paper, any questions regarding GOTO >usage >remain unclear, it means it was not read carefully enough. > >Fortunately, in THIS group the author need not be introduced. Amongst the >surveyed guys I mentioned above, only two had ever heard of Donald Knuth, >yet 90 >percent of them prided themselves as ultimate authority in programming >theory, >practice, and especially in structured programming. > >Kind regards, >==================== >Paul M. Dorfman >Jacksonville, FL >==================== > > >Richard DeVenezia wrote: > > > > >Can someone explain why a GOTO statement is classified as bad >programming? > > > > > > > I can't, because I don't think it is. Moderate use of all available > > language syntax is sensible. Badly constructed do loops can be just as >hard > > to understand as poorly structured GOTO code. I would rather be handed > > commented GOTO laden code than uncommented structured syntax code. > > > > It's been a long time since I looked at code as 'theorem' that has to be > > deduced as true or false. In this computer science mindset, gotos make >the > > deducing harder. > > > > In SAS macro, which lacks a %RETURN, %GOTO is a necessity for exiting a > > macro when certain requirement criteria are not met (i.e., this macro > > variable must be one of these values). Personally, I hate code that has > > ump-teen nested IF's because someone didn't want to use a goto to bypass > > some logic. > > > > Rich

_______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com