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: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: "Robert Martin" Subject: Re: Software landmines (loops) Date: 1998/09/03 Message-ID: <6snp4q$do2$1@hirame.wwa.com>#1/1 X-Deja-AN: 387721537 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-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-03T00:00:00+00:00 List-Id: Giovanni 8 wrote in message ... >> Robert Martin wrote: > >> 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. > >Non sequitur. It hasn't been concretely shown that single >exits at the bottom of a loop facilitates resource management, >and I know it makes error processing more difficult because >the erroneous state is retained while slogging through >irrelevant code to the bottom of the loop. It's a kludge. If the loop, or function, is properly structured, then upon detection of the error, no further code is executed except the code that must be executed to complete the loop. while (some condition) { if (vetting condition) do something interesting else report error } No slogging through irrelevant code, no retention of erroneous state. And, the extra benefit that the loop body is completely self contained. For example, I can put X and UNX calls at the top and bottom of the loop body, and guarantee that every X and UNX will be paired. while (some condition) { X(); if (vetting condition) do something interesting else report error UNX(); } >Multiple exits, OTOH, are elegant. They can be, but they also have costs: while (some condition) { if (!vetting condition) { report error; continue; } do something interesting; } Why this is any more elegant than the se/se version above, I can't say; though some folks do like to focus on the negative aspects of the invariants first. However, this code no longer has the nice self contained property. I can no longer add the X and UNX pair conveniently. Rather I must add UNX in two places: while (some condition) { X(); if (!vetting condition) { report error; UNX(); continue; } do something interesting; UNX(); } This is a concrete benefit of se/se. It is not an appeal to elegance or readability. It is not an appeal to prettiness or common sense. It is an ability that se/se code has, that is lost if the se/se style is not conformed to. Does that mean that se/se should be *always* be used? No, it's just a concrete, demonstrable, benefit. > >> It has also been shown that a multiple exit style is >> vulnerable to redundant code, and code for recovery of >> state... > >No, that has not been shown, I presume that the above is sufficient proof? Note the reduntant UNX() call in the second case. >& I contend that it is the >exit only from the bottom of a loop style that creates >a need for redundant or extraneous code, while multiple >exits eliminates it. Can you provide a case in point like the one above? >Multiple exits promote >Readability: The code follows the algorithm without any > extraneous matter. >Complexity: No extraneous matter. No multiple checks of > a condition or state. No flags. >Naturalness: The exit happens when the prescribed condition > is satisfied, not before, and not after. I think the above is rather subjective as the following rebuttal points out. se/se promotes: Readability: every control flow is explicit. Complexity management: since all control flows are explicit, adding new statement to existing control flows is trivial. Natrualness: the function happens when all the vetting conditions pass, all error recovery is at the end, and each is in its own specific control flow, so that specific error recovery is trivial. >"[I]n the early 1980s, a survey [1980 _Software Maintenance > Management_ pp 151-157 & 492-497] by [B.] Lientz & [E.] Swanson > of 487 data processing organizations showed that only 20% of > the maintenance effort was spent on corrective maintenance. > [And 42% on user requested enhancements.]" --- Carma McClure > 1992 _The 3 Rs of Software Automation_ pp 15-17 Precisely! Programs need changing a lot more than then need fixing. 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