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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public From: adam@irvine.com Subject: Re: Software landmines (was: Why C++ is successful) Date: 1998/08/19 Message-ID: <6rf59b$2ud$1@nnrp1.dejanews.com> X-Deja-AN: 382704395 References: <6qfhri$gs7$1@nnrp1.dejanews.com> <35cb8058.645630787@news.ne.mediaone.net> <902934874.2099.0.nnrp-10.c246a717@news.demon.co.uk> <6r1glm$bvh$1@nnrp1.dejanews.com> <6r9f8h$jtm$1@nnrp1.dejanews.com> <6renh8$ga7$1@nnrp1.dejanews.com> Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Wed Aug 19 18:24:44 1998 GMT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada X-Http-User-Agent: Mozilla/3.0 (X11; I; Linux 2.0.18 i586) Date: 1998-08-19T00:00:00+00:00 List-Id: In article <6renh8$ga7$1@nnrp1.dejanews.com>, ell@access.digex.net wrote: > A 'return', at least in C/C++/VB, returns you to the place the current > procedure was called from. 'goto' control flow can be endlessly channeled > here and there and never has to return to where the initial linear control > flow was originally diverted. That seems to be a huge advantage of 'return' > over 'goto'. No, to me this seems to be a huge advantage of "return" over "using too many goto's in your code that go every which way so that your code ends up looking like spaghetti." No one is supporting the idea of using that many goto's, the way programmers used to. Those who think goto's are OK think they should be limited to certain specific situations, and your objection really doesn't apply when goto's are used in that sort of careful, disciplined fashion. Of course, "goto" can be dangerous in the hands of an inexperienced programmer; but so, for that matter, can every other construct of every language. In the 22 years or so since programmers have started treating "goto" as an evil, I've seen some pretty strange arguments purporting to explain *why* goto's were bad. The most bizarre one I've seen argued that if your code is structured as follows: Transformation-1; goto L; Transformation-2; L: .... where Transformation-1 and Transformation-2 are sequences of statements or something else that transform your current program state from one thing to another, then the presence of "goto" in effect means that your code contains the inverse function of Transformation-2, which cancels the effect of Transformation-2. The author offered this as an explanation why "goto" makes code harder to understand. I don't remember exactly where I read this, but it was in one of the ACM publications. Of course, this is nonsense. There are good reasons why a researcher might want to think of a "program" as a sequence of mathematical transformations on the program state, but an ordinary programmer trying to write correct code, or to read or maintain someone else's code, isn't going to think about things that way. That's why I'm skeptical about most of the arguments I see about why GOTO IS EVIL. There often seems to be an implicit assumption that mathematical purity, or an aesthetically beautiful program structure, or something similar, equals readability, but that isn't the case. So when I see statements like "'goto' control flow can be endlessly channeled here and there and never has to return to where the initial linear control flow was originally diverted", my reaction is, "So what?" This argument contains no explanation *why* this makes programs harder to work with. So, personally, I think arguments against "goto" (or against any other construction) should demonstrate things from the programmer's point of view. That is, how does this EVIL NASTY construct actually make it harder for a programmer to understand what's going on, or make it easier for a programmer to miss something and write incorrect code? If the argument doesn't address the issue from that angle, it's worthless, IMHO. Now, here are a couple arguments on the other side: (1) Say you want to avoid the EVIL NASTY "goto" by putting the code into a subroutine and using "return". Well, you have to give the subroutine a name. In place of the nested "if" causing the problem, you'll have a call to this subroutine. Now, when a programmer looks through the main line of code, she'll see a call to this subroutine, and she'll have to know what it does. Can you give the subroutine a name that will make it obvious to the maintenance programmer what's going on? Sometimes you can. But if all you're doing is extracting some code and sticking it in a subroutine, most of the time you can't give it a good descriptive name, since it reflects just a random sequence of statements and not a concept that can be easily compartmentalized. So in this case, IMHO doing this is worse than using "goto", since it makes the program less clear. Of course, you can probably figure out a way to redesign the code to make it clear, and your code will be more readable since it has smaller, more compact subroutines that perform a well-defined purpose. But this just illustrates the importance of good design in general; a programmer who simply says "RETURN is a lot better than GOTO" and moves code around just to avoid the GOTO is unlikely to end up with a more readable and maintainable program. (2) (This one is about "continue", since Charles Hixson later argued that this was also superior to "goto" for the same reasons.) If you have a loop that looks like: while (blah-blah) { some-if-statements... some-more-if-statements... xxx; yyy; zzz; } someone reading the program might assume that xxx, yyy, and zzz are always going to happen before the loop repeats. So if there's something new that needs to be done during every loop iteration, it looks like you can just add it to the end of the loop, after zzz. If there's a "continue" statement somewhere above that, this assumption is incorrect and your modification may well be wrong. If you replace the "continue" with a "goto", at least there will be a label somewhere toward the bottom of the loop, alerting you to the fact that you will have to decide whether to put the new code before or after the label, or look for the place where this label is goto'ed. In fact, this is exactly why I stopped using "continue" when I was a C programmer. (I didn't replace them with goto's, I used Boolean flags instead.) Now all of this may be a matter of how each individual programmer tends to think when they look at programs. The point is that, based on my experience, arguments about "returning to where the linear control flow was diverted" and "restricted compass" don't make a whole lot of sense in the real world. GOTO can be used in ways that enhance readability or in ways that impair it, and so can every other feature of every language. -- Adam -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum