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=0.7 required=5.0 tests=BAYES_00,INVALID_MSGID, PDS_OTHER_BAD_TLD 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: "Larry Brasfield" Subject: Re: Software landmines (loops) Date: 1998/08/31 Message-ID: #1/1 X-Deja-AN: 386576147 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> <35EB1706.22E7E52E@draper.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Organization: Serendipitous Endeavors NNTP-Posting-Date: Mon, 31 Aug 1998 15:12:50 PDT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-08-31T00:00:00+00:00 List-Id: Tim McDermott wrote in message <35EB1706.22E7E52E@draper.com>... > > >Matthew Heaney wrote: > >> Here's is something I whipped up for another post recently. It's an >> equality operator for a bounded stack. >> >> The implementation of the function has multiple returns. >> >> Does this implementation fit your definition of spaghetti code? Not mine. Without significant effort, I can translate your code into "False if lengths differ, or if an element differs, else True". The concept of returning a query result when and where it becomes known cannot degrade clarity as I perceive it. >> Would the implementation be better by not using multiple returns? >> >> function "=" (L, R : Stack_Type) return Boolean is >> begin >> >> if L.Top /= R.Top then >> return False; >> end if; >> >> for Index in Positive range 1 .. L.Top loop >> if L.Items (Index) /= R.Items (Index) then >> return False; >> end if; >> end loop; >> >> return True; >> >> end "="; >> >> My feeling is that trying to implement this operation using only a >> single return would just make it more complicated. I think this is a poor example for the structure issue. A better one, IMO, is one where state must be modified and invariants discerned to be maintained "while" some appropriately understood transformation is effected. >How about this: > > function "=" (L, R : Stack_Type) return Boolean is >begin > > Boolean isEqual = True; > Positive Index = 1; > > if L.Top /= R.Top then > isEqual = False; > end if; > > while Index < L.Top && isEqual loop > if L.Items (Index) /= R.Items (Index) then > isEqual = False; > end if; > Index++; > end loop; > > return isEqual; > >end "="; > >What Dykstra was getting at with single entance, single exit is that you can >attempt to reason about the programs that are well structured. In the >second version, you can make assertions about pre- and post-conditions. In >fact they jump out of the loop test. That is not the case with the first >version. A bit overstated in this case, I think. But your point is important. There seem to be two ways that people analyze program segments: (1) What the code does; and (2) What is true because the code runs/ran. (I do not count a myriad of fuzzy and inneffective ways.) Multiple exits and other more complicated flow graphs impede (but do not necessarily defeat) a "What is true" analysis, but do not have as much effect on a "What will/can happen when this runs" analysis, unless the flow of control becomes difficult to sort out. I maintain that "What is true" analysis is ultimately more effective and reliable, especially as it is composed from smaller chunks of analysis. At higher levels than short, readily grasped partial screen code fragments, simpler flow graphs are a bigger win than is apparent from the small examples used to illustrate such ideas, especially for those who take the "What is true" approach. I think a lot of the disagreement over the merits of the less simple structure (short spaghetti?) arises from differences in how people comprehend code. I once worked with a brilliant fellow whose code drove me nuts (momentarily!) because his way of looking at it was different from mine, in the way I've suggested. (No offense intended, if you're reading this, D.) That said, I find the addition of extra flags just to remove an edge from the flow graph to be a (slight) hindrance to comprehension. --Larry Brasfield Above opinions may be mine alone. (Humans may reply at unundered larry_br@sea_net.com )