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: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: Matthew Heaney Subject: Re: Software landmines (loops) Date: 1998/09/02 Message-ID: #1/1 X-Deja-AN: 387048968 Sender: matt@mheaney.ni.net 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> <35EAEC47.164424A7@s054.aone.net.au> <35EBBFAF.DE38C061@s054.aone.net.au> <35EC28BD.351F33DF@s054.aone.net.au> NNTP-Posting-Date: Tue, 01 Sep 1998 23:55:11 PDT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-02T00:00:00+00:00 List-Id: Loryn Jenkins writes: > Now, someone else was kind enough to show me an even simpler way of > doing this ... albeit marginally less efficient (and again, I don't care > about this criteria, unless my application beforms below specification > and my profiler shows me that this is a hot spot). > > equal (l,r: LIST): BOOLEAN is > require > l /= Void and r /= Void > do > from > Result := (l.count = r.count) > l.start; r.start > until > not Result or l.off > loop > Result := (l.item = r.item) > l.forth; r.forth > end > end > > This, at least, loses your nesting objection. In fact, it has less > nesting than your original example. However, it might mislead unless the > reader was aware of this sort of idiom. (It does simplify things though; > so I think I'll be using this style, where appropriate.) I like that there's less nesting, but still have a couple of issues with it: 1) The decision table for the predicate still has 4 rules instead of 2. 2) It still bothers me a little that once you calculate the value of Result (the second time, when comparing items), you still do some work after (to increment the iterators), even though the result may already be False. The latter point is only a nit. It's the first point that puts a bee in my bonnet. It may not seem like much in this example, because we're "only" going from 2 rules to 4. But things get scary really fast when going 4 to 8. This was my experience trying to decipher someone else's post, in which a flag was added to a decision table with 4 rules, doubling the size to 8. I wouldn't have been able to figure things out without using a decision table. (I haven't caught on to K-maps yet, but decision tables are my best friend.) BTW: Treat minimizing nesting levels seriously. Whereas Miller's limit was 7 plus or minus 2, for a linear sequence of items, the limit is even lower (around 3) for nested relationships. (This info I read in Structured Design, by Constantine & Yourdon.)