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: 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: wallace@netcom.com (David E. Wallace) Subject: Re: Software landmines (loops) Date: 1998/09/02 Message-ID: #1/1 X-Deja-AN: 387311122 Sender: wallace@netcom7.netcom.com References: <35f51e53.48044143@ Organization: Netcom Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-02T00:00:00+00:00 List-Id: In article <6shunm$47g$1@hirame.wwa.com>, Robert Martin wrote: >This is, in fact, a characteristic of any good OO design that conforms to >the Open/Closed principle. New featuers are added by adding new code; not >by changing old working code. >Nevertheless, functions sometimes do change; and when they do its nice to >have the structured so as to facilitate those changes. But your argument against multiple exits was that even if they save effort in initial development, they cost you effort during the maintenance phase when you have to change the function to allocate and deallocate a resource. If such changes are rare, then the amount of effort saved during such maintenance has to be huge in order to justify the tradeoff. In particular, let's assume that the amount of effort saved per routine in initial development by using multiple exits is X. If 10% of the routines are subsequently modified in maintenance, and 10% of the changes involve adding an allocate/deallocate action that crosses these multiple exit points (very generous estimates in my opinion), and the average routine that is modified is modified 5 times during the course of maintenance, then the effort saved per allocation action added needs to be X/((.1)(.1)(5)) = 20X in order to break even. That calculation doesn't even take the time value of effort into account - a resource saved today is worth more than the same resource saved in the future, both because of the time value of money, and also because many new projects never make it into a significant maintenance phase, in which case any future savings projected are non-existent. So even with these very generous assumptions, you need to save substantially more than 20 times the effort in order to make the tradeoff worthwhile. If instead we assume that only 1% of the routines are modified, and only 5% of the changes involve adding such spanning allocates, then the maintenance effort saved needs to be X/((.01)(.05)(5)) = 400X, not counting the time value of effort. Such a large effort would never be justified (IMO) - if it really cost that much, you would simply rewrite the offending routine instead of modifying it. Note that the only allocate/deallocate pairs that are complicated by the presence of multiple exits are those where (1): an early exit occurs between the time of allocation and deallocation, and (2): the exit transfers control to a point subsequent to the deallocation. Early returns from a function prior to the initial allocation are not a problem, nor are break/continue style exits from a loop if the loop is contained within the allocate/deallocate span. So only a fraction of the allocate/deallocate additions will encounter problems with multiple exits. I can live with some contortions in those cases in order to simplify the initial development. -- Dave Wallace (wallace@netcom.com) It is quite humbling to realize that the storage occupied by the longest line from a typical Usenet posting is sufficient to provide a state space so vast that all the computation power in the world can not conquer it.