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: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public From: Robert Oliver Subject: Re: Software landmines (loops) Date: 1998/09/02 Message-ID: <35EDAC92.538A@hfl.tc.faa.gov>#1/1 X-Deja-AN: 387250455 Content-Transfer-Encoding: 7bit References: <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> <904556531.666222@miso.it.uq.edu.au> <6sgror$je8$3@news.indigo.ie> <6sh3qn$9p2$1@hirame.wwa.com> <35ece7ee.1489912@news.erols.com> <35ED7082.1889@hfl.tc.faa.gov> <8SeH1.542$495.132579351@newsreader.digex.net> Content-Type: text/plain; charset=us-ascii Organization: FAA Technical Center, Pomona, NJ Mime-Version: 1.0 Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-02T00:00:00+00:00 List-Id: Ell wrote: > > In comp.object Robert Oliver wrote: > : Ell wrote: > > :> The assertion that "single entry, single exit" is a required, or even > :> desirable, maxim of structured programming is a myth. > :> > :> No one (including RCM) can show that this maxim is in fact a coding > :> heuristic put forward by any of the founders of the structured > :> paradigm. [Check past posts in this thread.] > > : Edward Yourdan, in his book Techniques of Program Structure and Design > : discusses this article: > > : C. Bohm and G. Jacopini, "Flow Diagrams, Turing Machines, and Languages > : with Only two Formation Rules", Communications of the ACM, May 1996, > : pages 366-371. > > : (Is this not *the* foundational article for structured programming?) > > How can an artile written in '96 be *the* foundational article for > the structured programming paradigm which gained currency in the late > '70's? Clearly it can't be. It should have read 1966. My typo. > > : Yourdan says: > > : "According to Bohm and Jacopini, we need three basic building blocks in > : order to construct a program: > > : 1. A process box. > : 2. A generalized loop mechanism. > : 3. A binary-decision mechanism. > > : The process box, shown in Fig. 4.1, may be thought of as a single > : computational statement (or machine language instruction) *or as any > : other proper conputational sequence with only one entry and one exit* - > : such as a subtoutine." > > Where is the proof that this underlays the structured paradigm and an > assertion that something is "proper" doesn't make it so. What structured > programming avoided was unstructured flow control. It encouraged the use > of procedure/routine calls over 'goto'. Yes, but there is more to it. Unstructured flow control was replaced by one or more of the previously mentioned programming constructs, process, loop, or decision. This was to be accomplished at all levels of code from main() to individual instructions. Bohm and Jacopini proved that one could write any realistic (proper) program using only these constructs. Sequences of instructions (or other process boxes) could be transformed into a process box with a single entry and single exit. Loops and decision mechanisms could be similarly transformed. In fact, using only these constructs ones code must be decomposable into blocks with only a single entry and exit. So, the point I wanted to make is that early on (Yourdon's book was published in 1975) was known as a common characteristic of structured programming. > Along with entry into a procedure > via a call, the use of 'return' is structured flow control; 'return' can > only go back to the calling procedure, unlike 'goto' which can branch to a > label anywhere. It's interesting that you use the fact that return always returns the program to a single exit point (the calling procedure) as an argument that this technique is structured. Indeed, it is at the procedure level. (Just, curious. Would you allow goto's if they could not leave the scope of the procedure? Probably not.) I am not arguing against all use of multiple returns in a procedure or function. I often write a function like this: void AFunction(...) { if (SomeCondition) return; if (AnotherCondition) return; if (AThirdCondition) return; // now do the real work... return; } I think this makes sense when AFunction is called from many places and the conditions need to be tested each time. I can look at the beginning of the function and know that there will be nothing done in these three circumstances. It's not without danger as RCM has pointed out, but I often choose to live with the risk. Of course, it could also be written as: void AFunction(...) { if not (SomeCondition) and not (AnotherCondition) and not (AThirdCondition) then // now do the real work... endif return; } Bob Oliver