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,a7f223906eb859a X-Google-Attributes: gid103376,public From: adam@irvine.com (Adam Beneschan) Subject: Re: GOTO considered necessary Date: 1997/06/23 Message-ID: <5ombp9$c3a$1@krusty.irvine.com>#1/1 X-Deja-AN: 252071944 References: <5n977i$2cmc$1@prime.imagin.net> Organization: /z/news/newsctl/organization Newsgroups: comp.lang.ada Date: 1997-06-23T00:00:00+00:00 List-Id: yeung@reed.edu (Woodrow Yeung) writes: > >> THere are many obvious examples, one of the most familiar is to provide >> a continue facility for loops >> >> while ..... loop >> ... >> <> >> end loop; > >Oh dear, I have to disagree with this on two levels. It's far cleaner to >have a continue control structure than using a goto to implement it. . . . I have to disagree. When I used to program in C, I made a rule for myself not to use the "continue" statement. The reason: When I did use it in a loop, it worked fine, but then I'd find I had to make a modification that required that some extra actions to be taken at the end of each loop, before going to the next iteration. So I'd add those changes just before the closing }. All of a sudden, "continue" no longer worked; if I had any continue's up in the remainder of the loop code, I would have to search for them so that I could replace them with something else, and if I forgot, oops, I just put a bug into the program. At least if you have a goto-label construct: while ..... loop ... <> end loop; Now, when you have to add something just before "end loop", at least the presence of a label alerts you to the fact that something might be jumping there in order to perform a "continue"; now, you have to decide whether to add your code after or before the label. But you're less likely to make a modification that would screw things up. At least, that's my experience. Sure, one could come up with a case where "break" (or "exit", in Ada) has the same problem, but my experience is that problems like this don't occur--or rarely occur--with exit constructs; while they seem to be more frequent with "continue". I don't know why "continue" should be considered cleaner than an appropriate GOTO construct; I don't know what definition of cleanliness would make this so, except for one that proclaims that GOTO's are inherently unclean just because they are. I had to get over this attitude when programming in COBOL 66. [I think I got the language version right this time. :)] (BTW, I'm not likely to use *either* construct: boolean variables seem to work better for me.) -- Adam