From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,99222a5bd46ef3c9 X-Google-Attributes: gid103376,public From: mheaney@ni.net (Matthew Heaney) Subject: Re: GOTO considered necessary (reworked) Date: 1997/06/14 Message-ID: #1/1 X-Deja-AN: 248418252 References: <5nn2fm$11dk$1@prime.imagin.net> <5nufle$d1q$1@prime.imagin.net> Organization: Estormza Software Newsgroups: comp.lang.ada Date: 1997-06-14T00:00:00+00:00 List-Id: In article <5nufle$d1q$1@prime.imagin.net>, smize@imagin.net (Samuel Mize) wrote: >As I said in my other reply, my main point was just to put a writeup >somewhere so we can tell people "yes, that's a good question -- the >issues are discussed in ". > >Nobody replied "This is all covered in XXX," so I have to assume that >there isn't already a good issue-specific write-up to point people at. Good idea. Did you talk to Magnus? Can he add something to the FAQ? This was the ostensible purpose of the SPC Quality and Style Guidelines; perhaps we need modify that document to make it more clear when a goto really is the preferred control structure. I for one am not averse to these types of discussions. It's not the goto itself that's interesting: it's the discussion that it engenders that creates awareness of the fact that a lot coding standards out there are pretty silly. Any coding convention that says Thou Shalt Not Use Gotos is a silly coding standard, and we have to make people aware of that. Implementing a finite state machine (a scanner, say) is very natural using gotos, and we should proudly state that in writing somewhere. Obviously, when a higher-level control structure will do, use it, but that does not mean never use gotos. There's a great section in the 2nd ed of Meyer's Object-Oriented Software Construction (an important book that every software engineer and his manager should read), where he explains that a "rule" should be phrased as a "guideline, plus a list of those times when the guideline doesn't apply." Shops preparing a coding standard would do well to follow Meyer's advice. The goal always is to simplify the code, so a standard should state what language tools should be used for what kinds of problems, including stating that gotos are useful for implementing FSMs. Ada all by itself is a "tool for simplifying the code," so my expectation is that Ada coding standards be pretty slim and simple. However, that is often not the case in many shops. Why is this? A lot of really smart guys from all over the world debated how to design a language that was safe and simplifies programming, so why are shops writing huge complex coding standards to "simplify" Ada programming? It's already simple! Another "rule" similar to not using gotos is to not use early returns from a subprogram, or not use an exit from a loop. Why would you ban the use of these constructs? Computer scientists from all over the world decided that these features were a good thing, or else they wouldn't have made it into the language. So I always need to ask a shop that prohibits them, What do you know that they don't? As if adding a flag to an already-complex loop predicate is better than an exit! What are these people thinking? (A question perhaps better phrased as, Why are these people not thinking?) -------------------------------------------------------------------- Matthew Heaney Software Development Consultant (818) 985-1271