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: 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: doylep@ecf.toronto.edu (Patrick Doyle) Subject: Re: Software landmines (loops) Date: 1998/09/02 Message-ID: #1/1 X-Deja-AN: 387206937 X-Nntp-Posting-Host: spark19.ecf Sender: news@ecf.toronto.edu (News Administrator) References: <35f51e53.48044143@ Organization: University of Toronto, Engineering Computing Facility Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-02T00:00:00+00:00 List-Id: In article , Matthew Heaney wrote: > >Loryn Jenkins writes: > >> equal (l,r: LIST): BOOLEAN is >> require >> l /= Void and r /= Void >> do >> Result := l.count /= r.count >> if Result then >> from >> l.start; r.start >> until >> not Result or l.off >> loop >> Result := l.item /= r.item >> l.forth; r.forth >> end >> end >> end > > [...] > >No, no, not the same here. > >If the test l.count /= r.count returns False, then you know immediately >what the return value of the function is, so why not deliver that >information right away? That way you can remove the test of result >(reducing the level of nesting), and simplify the predicate, No, if the test returns False then the *computer* knows immediately what the return value of the function is. But remember that it's the reader of the code that is important; he's the one that must know what's going on. I can tell by the line "until not Result or l.off" that either we'll go the the end of the loop or else we'll quit early if Result becomes false. I don't have to mentally single-step the code to find that out; it's right there in the "until" clause. >(By way of analogy, if you've found the house, then you can park in the >driveway right way, instead of driving to the end of the block to >announce that you found the house.) Right, this would be the best idea if, in the analogy, the programmer were the driver. However, it's the computer that's the driver here. The programmer is the one who told the driver to find the house. (At this point, the analogy becomes strained beyond all recognition... :-) >Let's once again compare the decision tables. If we re-write the code, >to put it into Matt-like (because Matt likes it) syntax: > > >equal (l,r: LIST): BOOLEAN is > require > l /= Void and r /= Void > do > if l.count /= r.count then > return False > end > > from > l.start; r.start > until > l.off > loop > if l.item /= r.item then > return False > end > > l.forth; r.forth > end > > return True > end > > >This version has only two rules in the decision table for the loop predicate: > > 1 2 >l.off T F Right, so you've just made it really easy for the computer to execute the loop. But now I have to mentally single-step the entire body of the function to understand it. Particularly, I have to read every line in the loop body to understand what conditions will hold upon loop/routine termination. In Loryn's version, this information appears in one place, so it's much easier to verify that the loop does what it's supposed to do. After all, the whole point of a loop like this one is to cause certain conditions to hold when the loop terminates, right? -PD -- -- Patrick Doyle doylep@ecf.toronto.edu