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: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public From: mfinney@lynchburg.net Subject: Re: Software landmines (loops) Date: 1998/09/03 Message-ID: #1/1 X-Deja-AN: 387414153 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> <6simjo$jnh$1@hirame.wwa.com> X-Complaints-To: Abuse Role , We Care X-Trace: newsread.com 904809184 208.197.56.125 (Thu, 03 Sep 1998 03:53:04 EDT) Organization: Lynchburg.net (lynchburg.net) Reply-To: mfinney@lynchburg.net NNTP-Posting-Date: Thu, 03 Sep 1998 03:53:04 EDT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-03T00:00:00+00:00 List-Id: In <6simjo$jnh$1@hirame.wwa.com>, "Robert Martin" writes: >mfinney@lynchburg.net wrote in message ... >>And, as far as maintainability is concerned, I strictly use tree-structured >>programming and have *never* found it to be a maintenance problem. >>Sure, sometimes code transformations are required during maintenance, >>but they are sometimes required during coding. So what? There is no >>way to write code that never requires code transformations during >>maintenance, and trying to do so just makes the code harder to >>understand and ultimately increases maintenance cost. Far better is >>to endevour to reach 0 bugs so that maintenance is never required. >>Not easy, perhaps, but it is getting closer and closer every day. I >>personally am running somewhere around 0.0001 and 0.0002 errors >>per line of code -- prior to quality assurance getting the code. >Reaching zero bugs may not have that big an impact on maintenance, since >much of maintenance has to do with changes to the requirements. Reaching zero bugs means that changes are made by development rather than maintenance. That distinction is, of course, a matter of definition. It also depends on the ratio between code correction and requirement changes. >In any case, I note that in this thread nearly every article that advocates >multiple exits evokes either readability, complexity, or naturalness as the >justification. I contend that these are highly subjective things, that are >not shared by all programmers alike. Certainly true. But there does tend to be a rough consensus. Discussions like this tend to refine that consensus. >I also contend that >these issues are somewhat emotional, as evidenced by the terms such as >"twist", "warp", "bend", "religious argument", etc. that have also been used >in this thread. Quite true, although for the record I must say that I used the term "twist" as a synonym for "roll" or "rotate" and in an emotionally negative manner. The terms "warp" and "bend" were used to indicate the emotional "feel" of forcing code into a perceived unnatural state. >So, it seems what we have here is "gut feelings" warring against empirical >data. I would not agree with that. First, the "benefits" of structured programming have not been shown that clearly, and second, there is evidence on the other side as well. And, generally what was measured in most studies that I have seen is the difference between structured programmend and completely unstructured programming. Not the difference between structured programming and tree-structured programming which is the point of this argument. The only study quoted so far, favors the middle exit which is actually irrelevant to the difference between structured programming and tree-structured programming. >In the end, the decision to use a structured style is a tradeoff. There are >benefits, and there are costs. And there are certainly situations in which >the costs outweight the benefits (e.g. quick an dirty programs that have >short lifetimes and require little maintenance during their life). It is >also true, however, that for a very large set of circumstances, the benefits >outweigh the costs. First, I don't know about you, but I don't write "quick and dirty" programs. I write all programs in the same manner, regardless of their audience or intended lifespan -- those targets change far too frequently. Secondly, the benefits of structured programming over tree-structured programming have *not* been demostrated, so far as I know. Michael Lee Finney