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: 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: "Robert Martin" Subject: Re: Software landmines (loops) Date: 1998/09/02 Message-ID: <6simjo$jnh$1@hirame.wwa.com>#1/1 X-Deja-AN: 387033605 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> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Organization: WorldWide Access - Midwestern Internet Services - www.wwa.com Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-02T00:00:00+00:00 List-Id: 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. 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. 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. 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. 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. Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (800) 338-6716 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (800) 338-6716 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan