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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, TO_NO_BRKTS_FROM_MSSP 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: Phil Goodwin Subject: Re: Software landmines (loops) Date: 1998/09/02 Message-ID: <6sk3r9$6sl$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 387193523 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-Http-Proxy: 1.0 x11.dejanews.com:80 (Squid/1.1.22) for client 38.222.136.64 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Wed Sep 02 18:47:04 1998 GMT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada X-Http-User-Agent: Mozilla/4.05 [en] (WinNT; I) Date: 1998-09-02T00:00:00+00:00 List-Id: Comments interspersed... In article <6simjo$jnh$1@hirame.wwa.com>, "Robert Martin" wrote: > > 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. Mike, I wish I'd written this... > Reaching zero bugs may not have that big an impact on maintenance, since > much of maintenance has to do with changes to the requirements. Granted. > 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. Indeed, what is readable, natural and > simple to me, may be opaque and convoluted to you. 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. Emotional arguments have been made on both sides. It is unfortunate since it obfuscates the discussion. I suggest that from here on out we eschew obfuscation. > Finally, I contend that the factors in favor of using a > single-entry/single-exit style are, on the other hand, quite concrete and > demonstrable. It has been shown that adhering to a structured style > facilitates both resource management and error processing. It has also > been shown that a multiple exit style is vulnerable to redundant code, and > code for recovery of state. It has also been shown that in some circumstances SE/SE can introduce redundant code and that it also requires code for maintenance of state. In general these problems are less pronounced with SE/SE and most often the benefits outweigh the costs. Sometimes, however, it's really best to do what's easiest until you run into a compelling reason not to. > So, it seems what we have here is "gut feelings" warring against empirical > data. I can understand why the gut reaction is so strong; multiple exits > are *eaiser* to write; and are, for some, easier to read. But those are not > the only, or even the most important, criteria for evaluating the quality of > a design. Maintainability is an issue too, and sometimes an overriding one. I think that you're overstating the case. It only makes sense to design code to be amenable to a particular kind of change if there is some reason to think that changes of that kind will actually occur. > 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. Now, that I agree with, wholeheartedly. I just want to avoid incurring a cost for a benifit that I will never actually use. Phil -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum