Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site busch.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!mgnetp!we53!busch!dcm From: dcm@busch.UUCP (Craig Miller) Newsgroups: net.lang.c Subject: Re: break, continue, return, goto (net.religion.c) Message-ID: <521@busch.UUCP> Date: Mon, 11-Nov-85 15:32:45 EST Article-I.D.: busch.521 Posted: Mon Nov 11 15:32:45 1985 Date-Received: Tue, 12-Nov-85 06:22:20 EST References: <771@whuxl.UUCP> <516@busch.UUCP> <779@whuxl.UUCP> Reply-To: dcm@busch.UUCP (Craig Miller) Distribution: net Organization: Anheuser-Busch Companies - St. Louis Missouri Lines: 131 In article <779@whuxl.UUCP> mike@whuxl.UUCP (BALDWIN) writes: >But I do object slightly to the code not being called top-down (structured). >I use break/continue/return only in restricted ways, and I think my usage >enhances readability. Unfortunately, my sample code wasn't vicious enough. Well, after rereading Mike's programming examples (the word 'code' has such negative connotations... :-), I think I was kinda harsh saying it wasn't 'top-down'. His stuff was readable, especially considering some of the abuses I've seen in the past. Things like: while (1) { /* yuck! */ if (a) break; if (b) break; if (c) return (0); if (d) return (0) } Stuff like this is what I was really aiming at. The programmer (?) in question here seemed too lazy to really think about what was going on. But, "this is my opinion only"... >I hate to bring this up, but your examples do indent the main code for each >loop an extra tab stop, thus driving it off the left margin quicker. A >trite point, I know, but it matters to me. True. True. True. After talking to another experienced C programmer here (btw, just because this is a brewery doesn't mean that all we do is drink :-), and thinking about it a bit, I came to the conclusion that a number of folks out there use breaks/return/continue for exactly that reason. They don't want the program spilling off the right margin of the screen. My response again is that if I find *my* programs spilling of the right margin, this indicates I can usually split the current function up into more concise functions and just call them. And since I use switch() like this: switch (something) { case A: stuff_for_A... break case B: etc. break; default: break; } I *really* run into such problems. (flames to /dev/null :-) > >OK, here are some modified bits of code for you to rearrange: > Well, I could go through all of this, but it's kinda time consuming (and long-distance consuming), so I'll pass. But if I did rearrange it, I would try to split up the block into separate, concise functions, if at all possible.... But if you wanted to squeeze it all into the current function, I admit it would be hard. (especially on an 80 column terminal! Where's my Sun at, anyway? :-) >Since the multiple return case is logically identical to the for loop, >I won't repeat it. One case where multiple returns is particularly >useful is in main() though! What about: Same idea with returns. If I have a function that logically wants to do a lot of work, I usually attempt to split it up into smaller functions, each doing a portion of the work. Example: main(argc, argv) int argc; char **argv; { int init(), dothework(), cleanup(), status; if ((status = init(&argc, &argv)) == SUCCESS) { status = dothework(argc, argv); if (cleanup() == FAILURE) status = FAILURE; } return (status); } Something in this flavor (this may be taking it a bit too far, but I like to push the real work down as far as possible...) >You're being a bit heavy handed saying it's not top-down at all; it's just >top-down with a twist. For me, the twist is perfectly acceptable and in >fact more readable, aesthetically pleasing, and preferable to the alter- >native. The canonical code is: True again. Like I said once before in a previous style discussion (that one was one curly braces, I think), the most important thing to me is that you're consistent throughout all of your programs. If you are, I can probably pick it up and read it. (usually :-) >Yea, this is a religious argument but I get real tired, as probably >you do, of people saying "Thou shalt not EVER use GOTO, BREAK, CONTINUE, >or RETURN (etc, etc) in a C program; it is NON-STRUCTURED and a >Segmentation Violation!" And anyhoo, I just *love* religious arguments! > >"Hey! Who tore up all my Michael Baldwin > wallpaper samples?" {at&t}!whuxl!mike Segmention violation? For some reason that reminds of a semi-funny thing that happened here. One of the programmers here, who is one of our converted C programmers, I believe, was testing a program on our 3B20 here, when she got an EMT trap (which I don't think she's ever seen before). That probably doesn't seem too funny, till you realize her login name was 'emt'. From what I hear, that startled her quite a bit. (sorry Elaine, but I had to tell that story sooner or later) Oh well, enough religion. That's what the C bible is for, right? :-) Craig Today's C question: how come C won't let you increment a global, static or automatic array name, but will let you increment an array name that's a function argument? Film at 11. -- Craig Miller {*}!ihnp4!we53!busch!dcm The Anheuser-Busch Companies; St. Louis, Mo. - Since I'm a consultant here and not an Anheuser-Busch employee, my views (or lack of) are strictly my own.