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: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public From: Charles Hixson Subject: Re: Software landmines (loops) Date: 1998/09/06 Message-ID: <35F2DBA2.98180722@earthlink.net>#1/1 X-Deja-AN: 388467927 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> <35F2496D.7C4BDC42@earthlink.net> <6su70s$db8$1@hirame.wwa.com> X-Posted-Path-Was: not-for-mail Content-Type: text/plain; charset=us-ascii X-ELN-Date: Sun Sep 6 12:01:34 1998 Organization: Mandala Fluteworks Mime-Version: 1.0 Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-06T00:00:00+00:00 List-Id: Robert Martin wrote: > ... > > But, as you noted, we can apply Demorgan's theorem and turn this into an AND > of factors > > if (!this AND !that AND !the_other) > then do something useful > > Just a transformation, And one that turns a multiple exit function into an > se/se function. > > we might then decide that long boolean equations are better split apart: > > if (!this) > if (!that) > if (!the_other) > then do something useful. > > Which is an idiom that we can learn to read as a set of ANDS. > > 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 However, this is only reasonably intelligible BECAUSE the "do something useful" is limited to a very few lines. I suppose that this could be an argument in favor of having small function bodies, but I generally find that the natural size of a function body is determined by local data dependencies, and that splitting off pieces that are actually connected with thick pipes makes things harder to understand. Therefore, if I can do some quick validity tests at the START of a routine, and return error codes if necessary, then that lets me express the functions real form without excessive internal checks. And yes, formally this is equivalent to wrapping the body of the routine in an if block, so that it could be mechanically transformed into a se/se form (if one had the correct software tool). But that form would be harder to understand. N.B.: One limitation that I advocate here is that the early returns from routines be performed BEFORE the routine does anything which would create any non-temporary changes. I.E., it's ok to initialize/change local variables, but not anything that is non-local, and not anything that would be remembered between calls. This limitation avoids the maintenance problems that have been described earlier as endemic to non-se/se routines.