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: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public From: prochak@my-dejanews.com Subject: Re: Software landmines (loops) Date: 1998/09/10 Message-ID: <6t9d4k$tdt$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 389844585 References: <6rf59b$2ud$1@nnrp1.dejanews.com> <6spia2$1s36$1@prime.imagin.net> <35F06D6A.91A3D34E@s054.aone.net.au> <6t6b3m$30j8$1@prime.imagin.net> <6t6shq$f53$1@nnrp1.dejanews.com> X-Http-Proxy: 1.0 x4.dejanews.com:80 (Squid/1.1.22) for client 151.110.127.15 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Thu Sep 10 20:34:28 1998 GMT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada X-Http-User-Agent: Mozilla/4.5b1 [en] (Win98; I) Date: 1998-09-10T00:00:00+00:00 List-Id: In article <6t6shq$f53$1@nnrp1.dejanews.com>, sureshvv@hotmail.com wrote: > In article <6t6b3m$30j8$1@prime.imagin.net>, > smize@imagin.net (Samuel Mize) wrote: > > > > One heuristic that is often helpful in improving clarity of expression > > is to break up a long, complex sequence into shorter, well-structured > > components. This is true in English and in code. > > > > Well said. The multi-return structure enables you to separate > code in small independent blocks, each of which may be examined > and understood with less interference from surrounding blocks. > The se-se structure creates large blocks, requiring more > context information. When followed religiously in a large block of code, the se-se rule does lead to this kind of problem. It doesn't have to if the code and language allows creating more functions/procedures to encapsulate the pieces of that large code block. But that also can go too far to where the main line of code is a sequence of procedure calls and the procedures are grotesquely short (one liners). A certain amount of this is the old maxim: everything in moderation. > > > That's the central intuition of "structured programming," as I > > understand the term, which is in a broad sense. Single entry/exit, > > end-exit loops, and other constraints, are specific approaches to > > defining the structures to be used. > > > > Agreed. In this case, se-se is a good starting point. But the tree > structure (as someone referred to it; i would be interested in a reference) > IMHO, is superior in capturing this intent of structured programming > (irresp. of if Dijkstra would approve of it). > > suresh > The tree structure can get out of hand also. If there are too many exits in the code, then I'd begin to question the design there too. I'm not sure who I agree with in this discussion. I understand the central principle of structured programming to be: predictability. Dijkstra and other theorists want se-se type code structures to be able to derive proofs about the code. Programmers (me) look at it as a way to know, when reading some code, where to look next when coming across a GOTO statement. In unstructured code, I'm forced to always do a linear search from the first line of the code listing. In structured code, I expect everything to "flow downhill" so the target must be later in the listing (except for well-defined loops, which I know exists because something labeled it so at the loop entry. ie the single entry is just as important as the single exit.) Actually, writing that last line, I realized what is perhaps a better way to state the structured programming principle: all code structures have a WELL-DEFINED entry and a WELL-DEFINED exit. So where necessary, there are early loop exits, there are multiple returns within functions, and whereever else goto's are NEEDED. But the goto's are not sprinkled thruout the code for arguements of "efficiency" or "code reuse". How do you know if it is WELL-DEFINED? That's what code reviews and walkthru's and software inspections are for. There are no absolutes. The code must fit the application, the department/company producing it, and must be maintainable as needed. That last part is where the predictability of the code structure pays off. As long as the previous coders keep the same style thruout a program, I can learn it much faster than if there is a jumble of styles (even if they all follow the se-se rule!). It is not the multiple exits that are directly harmful. In contrast, it is the well-defined structure that leads me to know how it exits so I can concentrate on the conditional clause which is application specific. I don't have to see the whole routine every time. Dijkstra may not agree with me, but goto's are not bad or good, but arbitrary use of goto's is always bad. -- Ed Prochak Magic Interface, Ltd. 440-498-3702 -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum