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: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public From: "Robert Martin" Subject: Re: Software landmines (loops) Date: 1998/09/03 Message-ID: <6smsi3$n8i$1@hirame.wwa.com>#1/1 X-Deja-AN: 387593026 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> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Organization: WorldWide Access - Midwestern Internet Services - www.wwa.com Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-03T00:00:00+00:00 List-Id: 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: 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. So, the benefit of multiple returns is not a reduction in nesting, but just an *apparent* reduction in nesting. The cost, on the other hand, is that the nesting will have to be unhidden later. Point 2 is certainly a cost. The creation of mutable state is always annoying. On the other hand, the loss of control flow state is also annoying. Both have their own benefits and costs. The cost of capturing state in se/se is paid once when you write the module, and once for every person who must understand it. The cost of rederiving state lost by merging control flows is paid every time the function changes in such a way that the state must be rederived. 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