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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: mfinney@lynchburg.net Subject: Re: Software landmines (loops) Date: 1998/09/06 Message-ID: <2xEI1.84$lR1.269198@newsread.com>#1/1 X-Deja-AN: 388518942 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> <6sgror$je8$3@news.indigo.ie> <6sh3qn$9p2$1@hirame.wwa.com> <6sk1k9$3r9$1@nnrp1.dejanews.com> <35F2F3F9.69ED1C30@earthlink.net> X-Complaints-To: Abuse Role , We Care X-Trace: newsread.com 905123006 208.229.14.143 (Sun, 06 Sep 1998 19:03:26 EDT) Organization: Lynchburg.net (lynchburg.net) Reply-To: mfinney@lynchburg.net NNTP-Posting-Date: Sun, 06 Sep 1998 19:03:26 EDT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-06T00:00:00+00:00 List-Id: In <35F2F3F9.69ED1C30@earthlink.net>, Charles Hixson writes: >mfinney@lynchburg.net wrote: >> >> In <6sk1k9$3r9$1@nnrp1.dejanews.com>, john-clonts@hlp.com writes: >> >> >What do you mean by 'tree-structured' programming? >> >.... >> For example... >> >> outer::while (someCondition) >> { >> // some code >> inner::while (anotherCondition) >> { >> // some code >> outer::break; // exit outermost loop >> inner::continue; // restart innermost loop >> outer::continue; // restart outermost loop >> inner::break; // exit innermost loop >> // some code >> } >> // some code >> } >> >.... >> Michael Lee Finney >I feel that this is a structure to be avoided when it is easy to do so. >I haven't needed this kind of sturcture more than about 10 times since >the '80's. OTOH, sometimes it's what the sturcture of the problem seems >to demand. Sometimes avoiding it would cause more problems than it >solves. In such a case, be VERY careful to make your code as clear and >obvious as possible, because this IS a >more-difficult-to-understand-than-usual idiom. I certainly don't need it often. I do frequently need the multiple return from a block or the n 1/2 loop (resulting in a mid-block loop break) which at least the first is not structured (but is tree-structured). And, there is a reasonable argument both ways about the mid-block loop break being structured because it is se-se, but the exit is neither at the top nor the bottom. I would personally argue that it meets the spirit, but not the letter of structured programming. It is, however, tree-structured. The need for the more comprehensive forms of tree-structured programming are rarer, but they do essentially encapsulate most of the need for more powerful control structures while maintaining most or all of the benefits of structured programming. I don't believe that I have ever written a program, even in assembly language, which was not tree-structured -- but I have written many programs, time and again, which are not structured just because here or there I needed just a bit more than is available with structured programming. And since efficiency *does* count -- at least sometimes -- adding flags or other forms of additional tests is generally not acceptable to me. Michael Lee Finney