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: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public From: Mike Spille Subject: Re: Software landmines (loops) Date: 1998/09/03 Message-ID: <35EEBA15.30C3CC76@tisny.com>#1/1 X-Deja-AN: 387605578 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> 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-03T00:00:00+00:00 List-Id: Robert Martin wrote: > > sureshvv@hotmail.com wrote in message <6smmhv$1kp$1@nnrp1.dejanews.com>... > >In article <6skqf3$9g0$1@hirame.wwa.com>, > > "Robert Martin" wrote: > > > >> Knowledge of the benefits and costs of > >> single-entry/single-exit functions should be firmly ingrained in all > >> software engineers. > > > >I would like to find out the costs that are associated with the se/se > >structure of functions. > > > >1. Increases level of nesting in code, making it potentially more complex. > >2. Requires adding flag variables which have to be tracked, making it > >more complex. > >3. Special conditions can become embedded in code rather than being readily > >apparent. > > 1 and 2 are certainly costs; although perhaps overstated. I don't > understand 3. > > As for 1, nesting level becomes explicit, whereas early returns hide the > true nesting level. Consider: > "True nesting level"? Sounds metaphysical. In a C-like language I define nesting level as "how many open braces have I got"? (oh, this works for me 'cause I always brace-ify if/do/while/for/etc statements, even for one liners). > void f() > { > if (condition.1) return; > if (condition.2) return; > do something useful > return; > } > > This is equivalent to: > > void f() > { > if (condition.1) return; > else if (condition.2) return; > else do something useful; > return; > }; > > Which, in reality, is: > > void f() > { > if (condition.1) return; > else{ > if (condition.2) return; > else { > do something useful; > } > } > }; > > So, early returns do not actually reduce nesting; they just appear to. The > problem is that subsequent changes to the function may force you to separate > the flows that multiple exits have combined. > Nesting is as nesting does. Your first example does not have any "hidden" nesting; it avoids nesting by using multiple-returns. Period. You may introduce nesting later on but that doesn't mean the nesting was hidden in the function, struggling to get out :-) I've seen the style you've shown above in example 3 in code before. It invariably was written by someone who religiously followed the 1 entrance/ 1 exit philosophy. The reality of reading such code was that the meat of function, the code that actually did "work" within the function, was buried under a pile of ifs, and forced the reader seperate the wheat from the chaff in a painful manner. In the first example above, it's immediately obvious where the "meat" is. To put it another way, example 1 puts emphasis on the "do something useful" section. Example 3 hides "do something useful", and emphasizes the condition checking instead. [snip] > 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