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: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public From: Richard Melvin Subject: Re: Software landmines (loops) Date: 1998/09/02 Message-ID: #1/1 X-Deja-AN: 387243825 X-NNTP-Posting-Host: radm.demon.co.uk:194.222.155.111 References: <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@news.erols.com> <6sdiav$e0g$1@hirame.wwa.com> <6sfcft$70p$1@hirame.wwa.com> <6shp40$ec8$1@nnrp1.dejanews.com> <6sie46$eb7$1@hirame.wwa.com> <6siijm$h1m$1@hirame.wwa.com> X-Complaints-To: abuse@demon.net X-Trace: news.demon.co.uk 904767915 nnrp-06:24532 NO-IDENT radm.demon.co.uk:194.222.155.111 Organization: n/a MIME-Version: 1.0 Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-02T00:00:00+00:00 List-Id: In article <6siijm$h1m$1@hirame.wwa.com>, Robert Martin writes > >Lets just say, for grins, that I must make a change to the loop. For some >odd reason I must count the number of times that the loop body completes. I'm sorry, this really is an invalid argument. Any change case must be based on functionality, not on the existing structure of the code. Otherwise I can blow any of your dependency management principles out of the water with a change case carefully designed to cause maximum pain and distress (e.g. 'all Visitors must be re-written to be case statements'). You wouldn't really agree that the above proved case statements were better, would you? Just because you're the only one using change-case based arguments, doesn't mean you're the only one thinking about design for maintainability. It'd be interesting to do a proper change-case comparison. I guess that would need a set of 5 or 6 reasonable, functionality-based changes to a function written in 'pure-structured' and 'tree-structured' styles. Changes that require restructuring count against, changes made correctly first time count for. As a control, you could throw in a true spaghetti implementation - if the analysis didn't show this was worse, then there's something wrong with the analysis. As a starter, try extending a fixed-length array comparison function to be a stack comparison :-) -- Richard Melvin