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,4b06f8f15f01a568 X-Google-Attributes: gid103376,public 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 From: Mike Spille Subject: Re: Software landmines (loops) Date: 1998/09/01 Message-ID: <35EC1B94.CAC23CB3@tisny.com>#1/1 X-Deja-AN: 386908159 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> 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-01T00:00:00+00:00 List-Id: Robert Martin wrote: > > Gerry Quinn wrote in message <6sgror$je8$3@news.indigo.ie>... > > >Multiple exits to a single destination are not spaghetti. > > Spaghetti is not a well defined term. > > However, multiple exits to a single destination represent a problem. The > two exits come from two different states within the algorithm. If the > single destination must do some work that depends upon that state (or if in > the future, that single destination must be modified to do work that depends > upon that state), then the code in the single destination is going to get > pretty ugly. > OK, what if the state does not change? For example, typical "search" functions check for validity of arguments, valid internal state, etc before continuing. These checks do not affect state, and if a check fails, there's no point in continuing. Why complicate matters with extra variables and nesting? I think the problem with this argument is people are trying to fit one solution to many problems. Not all functions aqcuire resources. And on the flip side, not all functions are stateless. Should you write your functions in such a way that you're ignorant of how it affects state?!?! Should you add over-head to functions that do not affect state, and by design, never will? NO! And if my function _does_ affect state, then it is unlikely I'll have multiple exits. If I do, they'll be in checks at the top asserting correctness, and returning null (or error, or whatever) at the top. So what do you do when the function "grows"? Well, first off, most functions (in my programs at least) don't grow. The majority are dinky 8 or 9 liners that don't change over time. The minority that _do_ change over time, tend to change alot. They're complex. Knowing "This code only has one exit point" does not add to my understanding of the code at all. And if I can't understand it, I _can't_ modify it. If it grows significantly, I split it into multiple functions. > 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