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: 109fba,9536f6d30d365d8a,start X-Google-Attributes: gid109fba,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: Ell Subject: Re: Software landmines (loops) Date: 1998/09/06 Message-ID: #1/1 X-Deja-AN: 388502085 References: <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> <35F0B5B0.8E2D0166@s054.aone.net.au> <905071271.568311@optional.cts.com> X-Complaints-To: abuse@digex.net X-Trace: newsreader.digex.net 905118240 205.197.245.196 (Sun, 06 Sep 1998 17:44:00 EDT) Organization: The Universe User-Agent: tin/pre-1.4-980226 (UNIX) (SunOS/4.1.4 (sun4m)) NNTP-Posting-Date: Sun, 06 Sep 1998 17:44:00 EDT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada,comp.lang.c++ Date: 1998-09-06T00:00:00+00:00 List-Id: In comp.object Will Rose wrote: : I'm not sure which book started this discussion, but Dijkstra's : "Notes on Structured Programming" in "Structured Programming", : Dahl, Dijkstra and Hoare, say inter alia: : "When we now take the position that it is not only the programmer's : task to produce a correct program but also to demonstrate its : correctness in a convincing manner, then the above remarks [on program : size and structure] have a profound influence on the programmer's : activity; the object he has to produce must be usefully structured." : : "The remaining part of this monograph will be mainly an exploration of : what program structure can be used to good advantage. In what follows : it will become apparent that program correctness is not my only concern, : program adaptability or manageability will be another. This stress on : program manageability is my deliberate choice, a choice that, therefore, : ..." Yes *this* is the overall *spirit* we should be working in. And quite often restricting a loop, or procedure to se/se makes things less maintainable in the judgement of a plurality or majority of project programmers. Multiple exits to enhance maintenance can work while preserving the ability to prove program correctness. This happens if multiple exits exist in a program which uses procedure calls and returns to calling procedures 99.5% of the time as I see it. : ...[description of flowcharts which] "share the property that they : have a single entry at the top and single exit at the bottom"... OK, the single entry at the top and single exit at the bottom of the flowchart, as a means of helping to prove correctness, and as they say of improving maintainability. As I see it they made no specification that when going through a physical coding structure coding that represents for example a diamond decision that we must have only a single exit out. In fact the graphical depiction of the decision diamond itself has *2* paths out it! 'Yes' and 'No', 'Greater', or 'Lesser', etc. : ...Alternatively: restricting ourselves to the three mentioned types : of decomposition leads to flowcharts of restricted topology compared : with the flowcharts one can make when arrows can be drawn from one : block leading to any other. ["Blocks" here certainly should be taken as procedures/functions/routines nowadays because I'm sure they would frown on going from one unencapsulated tagged block of code to another when we now have encapsulated procedures/functions/routines.] Certainly they aren't saying you shouldn't navigate to another "block", but that you must use discipline to get there. As you quote them: : "Compared with that greater freedom, to restrict oneself to the clauses : presents itself as a sequencing discipline." As I see it, proof and maintainability are fundamentally made easier by using procedure calls and returning to the caller, whether using multiple or single exits. Really, what better way overall is there to handle navigation in general? The se/se people in their attempt to preserve proof and maintainability are being too rigid and dogmatic. In fact many uses of se/se make proof and maintenance more difficult. The se/se people in trying to hard miss the point. The spirit and essence of what I get from Dahle and Dijkstra on structured programming is: 1) Use procedure calls and return to procedures 2) Design procedures as abstractions (Dijkstra in "Art of Literate Programming" by Knuth) Navigation should be from one highly coherent, loosely coupled task abstraction procedure to another. Navigation should not be from one isolated loop, branch, or process structure to another, but between complete task abstraction procedures/functions/routines. [Dijkstra also mentions creating a hierarchy of abstractions - a layered design.] Elliott -- :=***=: Objective * Pre-code Modelling * Holistic :=***=: Hallmarks of the best SW Engineering "The domain object model is the foundation of OOD." Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell Copyright 1998 Elliott. exclusive of others' writing. may be copied without permission only in the comp.* usenet and bitnet groups.