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: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: Mike Spille Subject: Re: Software landmines (loops) Date: 1998/09/04 Message-ID: <35F0484A.2108A9F@tisny.com>#1/1 X-Deja-AN: 388026858 Content-Transfer-Encoding: 7bit References: <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> <6rf59b$2ud$1@nnrp1.dejanews.com> <6rfra4$rul$1@nnrp1.dejanews.com> <35DBDD24.D003404D@calfp.co.uk> <6sbuod$fra$1@hirame.wwa.com> <35f51e53.48044143@ <904556531.666222@miso.it.uq.edu.au> <6sgror$je8$3@news.indigo.ie> <6sh3qn$9p2$1@hirame.wwa.com> <6shbca$66c$1@news.indigo.ie> <6shhq7$lut$1@hirame.wwa.com> <6sjbso$1lk$2@news.indigo.ie> <6sjijg$36r$1@hirame.wwa.com> <6skhcm$1dr$2@news.indigo.ie> <6skqf3$9g0$1@hirame.wwa.com> <6smmhv$1kp$1@nnrp1.dejanews.com> <6smsi3$n8i$1@hirame.wwa.com> <35EEBA15.30C3CC76@tisny.com> <6sn2lv$t6m$1@hirame.wwa.com> <35EEF0D1.939F1907@tisny.com> <6sp902$buj$1@nnrp1.dejanews.com> <6sph1s$or0$1@hirame.wwa.com> Organization: Transaction Information Systems Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-04T00:00:00+00:00 List-Id: Robert Martin wrote: > > > int f(char* name) // returns status value > { > int status = 0; > if (File* f = fopen(name, "r")) > { > if (char* buffer = malloc(80)) > { > DoSomethingUseful(f,buffer); > free(buffer); > } > else // malloc failure > { > Log("malloc failure"); > status = -2; > } > fclose(f); > } > else // fopen failure > { > Log("Failure to fopen"); > status = -1; > } > return status; > } > > Perhaps you think this is cumbersome. I don't. Cumbersome is a rather > subjective term. > I find it quite cumbersome, and error prone to boot. I'd do it as: int f(char* name) // returns status value { char buf[80]; FILE* f = fopen(name, "r"); if (f == NULL) { Log("Failure to fopen"); return (-1); } DoSomethingUseful(f,buf, sizeof(buf)); fclose (f); } That is, use a stack-based buffer and pass in the size of the char array to do something useful so it doesn't walk off the end of the buffer by mistake (assuming that DoSomethingUseful is smart enough to include a size argument). My point? I focused on what the routine was supposed to do, not on a methodology, and ended up with a more efficient, less error-prone, shorter version. (And I think it's more readable :-) [snip] > >The se/se strcuture often creates a monolithic paragraph, > > Quite to the contrary, the se/se structure is defined as a structure that is > recursively decomponsible into four discrete se/se control elements. The > recursive decomposition goes right down to the level of single lines of > code. Thus, an se/se structure cannot be monolithic (literally "one rock"). > Well...putting theory aside, you wrote a poor-performing, IMHO hard to read C routine (well, C++ since some declarations happen in the middle of the routine). You did this to demonstrate the positive aspect of se/se. I ignored theory, stared at your function for awhile, figured out what it was supposed to do semantically, and then wrote it to accomplish its function. My version puts error reporting next to where it happens (yours moves error-handling away from error-checking; the fclose test and handling code are far apart), doesn't waste time malloc()ing, and is alot shorter. I didn't consciously follow any paradigm or methodology - I just used the language features as clearly and consisely as I could. > >creating a scope that extends across many lines. > > Lots of things creates scopes that extend accross many lines. Functions, > classes, try blocks. I'll grant you that scopes should be as small as > possible in order to be understood. > > >In fact, I feel that the multiple-return structure is more in line with the > >"structured" organization of programs. > > You are free to feel that way, but the strict definition of SP does not > support your "feeling". > > Robert C. Martin | Design Consulting | Training courses offered: > Object Mentor | rmartin@oma.com | Object Oriented Design > 14619 N Somerset Cr | Tel: (800) 338-6716 | C++ > Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com > > "One of the great commandments of science is: > 'Mistrust arguments from authority.'" -- Carl Sagan -Mike