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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,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: <35EEF0D1.939F1907@tisny.com> X-Deja-AN: 387674033 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> 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: > > 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. Your second and third examples add a bunch of extra tokens a reader of the code has to scan. Turning this into single/entry, single/exit will do the same or add even more tokens. This enhanes maintainablility? > Indentation is one of the ways we represent nesting. The three functions > shown above use different indentation schemes. Nesting, on the other hand, > occurs when control flow splits. The branches below the split are nested. > > >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. > > All of the snippets above violate se/se; so anybody who religiously followed > se/se would not use any of them. > Whoops - my eyes failed me on that one. Mea culpa. > Also, I would advise that religiously following se/se, or any other > paradigm, is foolish. > > >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. > > It seems to me that in all of the styles above, the work is buried under a > pile of ifs. And the flowchart of the three shows this to be true as well. > I think you are really saying that the second and third show the work to be > indented to the right of a pile of ifs. > What my brain sees in case one is a bunch of constraint-type checks that "abort" if they fail. Following that is un-nested, unindented code which can rely on the guarantees made at the top of the function. The third case isn't as clear cut in my eyes. The meat of the code is physically contained within the constraint checks. In addition, if this code takes up more than a page, I have to worry about an else possibly being hung on to the end. > Now, in a real se/se function that checks a few things before doing the real > work, the real work will be the most indented part of the function. People > who train themselves to know that the real work is the stuff that is most > indented, have little trouble finding it. > I avoid syntax-level nesting (e.g. open curlies and indenting for C-based stuff) when I can, because I find nesting negatively impacts readability. This is highly subjective of course. > > > >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. > > It's odd, but that's exactly the statement I'd make about se/se. > > It seems to me that: > > if (A is right) > if (B is right) > if (C is right) > then do the work. > > emphasizes the work more than: > > if (A is wrong) then return; > if (B is wrong) then return; > if (C is wrong) then return; > do the work; > > So, I think the notion of "emphasis" is somewhat subjective. > Defintely so - I find having the most important code stuck in column X (where X can vary, depending on how many checks and the nesting level) very hard to follow over large programs. Having the important stuff at the zero indentation level seems much more natural. > 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