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: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: "Robert Martin" Subject: Re: Software landmines (loops) Date: 1998/09/03 Message-ID: <6snnhl$cjh$1@hirame.wwa.com>#1/1 X-Deja-AN: 387717541 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> 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: Mike Spille wrote in message <35EEF0D1.939F1907@tisny.com>... >Robert Martin wrote: >> >> Mike Spille wrote in message <35EEBA15.30C3CC76@tisny.com>... >> >Robert Martin wrote: >> >> > >> >> 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; >> >> } >> >> } >> >> }; >> >> >> > >> >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 :-) >> >> Draw the flowcharts of the three snippets above. You will find that they >> are identical. Now ask yourself whether or not nesting is a semantic >> quality, or just a comment. If nesting is a semantic quality, then how can >> three identical flowcharts have different nesting? On the other hand, if >> nesting has no semantic content, then why do we do it? >> >Well, I can make a semantically equivalent program out of gotos - so what? >I thought the point was readability and maintainability. It is. And I agree with you that, for most people at least, the first snippet is more readable than the other two simply because it has fewer tokens. >Your second and third examples add a bunch of extra tokens a reader of >the code has to scan. Correct, and I do not recommend them; the added tokens serve no extra purpose. I was just demonstrating that the first example was just as nested as the others (if not as indented). >Turning this into single/entry, single/exit will >do the same or add even more tokens. This enhanes maintainablility? It can. Yes, more tokens may be added. But in an se/se structure, each added token serves a purpose. It serves to expose a control flow that would otherwise be hidden, or to separate a control flow that would otherwise have been merged. Does this benefit offset the additional tokens? That depends up the kinds of changes that the function faces in the future. My own personal view is that the cost of the extra tokens is low, whereas the cost if separating control flows in the future is high, so I usually prefer to keep the control flows separate. 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