Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!tank!shamash!nis!quad!dts From: dts@quad.uucp (David T. Sandberg) Newsgroups: comp.misc Subject: Re: The "evil" GOTO (Was: 25 Years of BASIC) Message-ID: <137@quad.uucp> Date: 11 May 89 19:44:43 GMT References: <6974@ecsvax.UUCP> <13424@lanl.gov> Reply-To: dts@quad.uucp (David T. Sandberg) Organization: Quadric Systems, Richfield MN Lines: 89 In article <13424@lanl.gov> jlg@lanl.gov (Jim Giles) writes: |In article <852@umecs.cs.umu.se> christer@rachel.UUCP (Christer Ericson) writes: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Wrong person. The first set of comments you quoted are mine. |> ...... Sure, it's easy to see where a GOTO is leading when |> both the GOTO and it's target location appear right there on |> your 24-line screen, but when you are working on code of any |> significant size and complexity, the issue of knowing where |> the GOTO points to rears it's fugly head. For an example, |> pretend this article is a code segment. Now, quick, tell me |> where we're going... ;') | |Unfortunately, the _SAME_ problem exists when you introduce a boolean |to replace the GOTO. If you can't see the use of the flag right away, |then its presence in your code is just as mysterious as the GOTO is |(ie. where is this niggly little flag variable used?). Often you find |that the flag is used _several_ places - that's certainly not the case |with GOTOs. When you find the place where a flag is used you have no |assurance that you've found the _only_ use. The 'fan-out' of the |GOTO is one, the 'fan-out' of the boolean is unbounded. The "fan out" of a GOTO may be one, but the "fan in" of that GOTO's label is unbounded (any number of GOTOs can use it as an entry point). Also, GOTOs can jump to any part of the program which they like: different functions, different modules, etc. On the other hand, a flag is almost always set within the function of it's usage (or at least passed in as a parameter). You could counter that using a global flag would create the same kind of problem as GOTOs are subject to, but anyone who would use a global flag for controlling a conditional expression deserves what they get. |> Here's another code segment (label only): |> |> LOCATION: |> |> Now, quick, tell me where we're coming from! This was Christor Ericson's followup comment to my original article, and it was well said. I wish I had said as much my first time around. |Now, in truth, the 'fan-in' of a boolean and a label are exactly |of the same complexity. Selecting mnemonic identifiers for either |will increase readibility. So will the presence of appropriate |comments. No, the "fan-in" of a *global* boolean and a label are exactly of the same complexity. A local flag (the common & preferred method) has a much more restricted scope. You are right, though, that meaningful identifiers and comments help in both cases. |Which _looks_ best to _you_ is a subjective decision. Sounds about right, but your original contention was that, in the code fragments you presented, the GOTO version should look better to all onlookers. I hope I've convinced you that I sincerely would rather work with the structured version. |To be sure, GOTOs can be abused to produce spaghetti code. Unfortunately, |flags and/or conditions can implement the _same_ spaghetti! I have |seen well "structured" (no GOTOs) code in which the flow of control |bounces all over everywhere (lots of conditions and flags, lots of |IFs and CASEs, all inside a loop). I'll give you that. Any structure can be used for good or bad code. My observation is that the GOTO leads more directly to bad code than to good. Now, I wouldn't go into convulsions if confronted by the short little GOTO hops you presented earlier, but if I was asked to write software to accomplish those tasks, I would certainly find it more natural to produce code resembling the structured example. |By the way, the POINTER in data structuring is isomorphic to the GOTO |in flow control. The POINTER can be abused to produce spaghetti data |structures. Any anti-GOTO fanatics out there want to ban the POINTER |too? This is an interesting point which I'll have to consider. (Not that I think it likely that I'll start using GOTOs or give up pointers entirely, mind you... ;') -- char *david_sandberg() { return ( dts@quad.uucp || uunet!rosevax!sialis!quad!dts ); }