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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: mfinney@lynchburg.net Subject: Re: Software landmines (loops) Date: 1998/09/02 Message-ID: #1/1 X-Deja-AN: 387025783 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-Complaints-To: Abuse Role , We Care X-Trace: newsread.com 904712494 208.197.56.138 (Wed, 02 Sep 1998 01:01:34 EDT) Organization: Lynchburg.net (lynchburg.net) Reply-To: mfinney@lynchburg.net NNTP-Posting-Date: Wed, 02 Sep 1998 01:01:34 EDT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-02T00:00:00+00:00 List-Id: In <6sh3qn$9p2$1@hirame.wwa.com>, "Robert Martin" writes: >However, multiple exits to a single destination represent a problem. The >two exits come from two different states within the algorithm. If the >single destination must do some work that depends upon that state (or if in >the future, that single destination must be modified to do work that depends >upon that state), then the code in the single destination is going to get >pretty ugly. I have been following this thread for a while (or at least part of the thread), and it seems to me that the basic argument is between the use of structured programming which requires a single entry and single exit and of tree- structured programming which allows multiple-level breaks/continues, but not arbitrary jumps into blocks. It turns out that tree-structured programming covers almost all of the flow graphs actually encountered by compilers which are not undecomposable and provides the necessary flow graph assurances for optimization (I do have a reference on that, but have just finished moving and everything is in boxes, so regrettably I can't provide it at this time). Multiple exits from a block do require the compiler to add extra control flow paths to a single exit point for some algorithms, but that is trivial control flow transformation by the compiler -- but not for the programmer because modern languages do not generally provide adequate control structures (other than goto) to represent the extra control flow paths. I personally feel that structured programming is a very good idea, but like most things is an extreme which is better with a little compromise. I see tree-structured programming as that compromise. It is true that multiple exits arrive from different states -- but presumably they all satisify the exit postcondition, and that is what should be used for subsequent programming (assuming that the exit postcondition is clearly stated). In a routine such as the one being used for an example, it seems clear that multiple exits do not harm and actually improve code readability. It has been suggested that the need for maintenance is a reason to twist the code unnaturally -- but that is where using a multiple level exit instead of returns would solve the problem (true, C/C++ does not directly provide multiple level exits, but they can be "faked"). It has been suggested that mid-loop exits (which can still be considered structured code because they have a single entry and a single exit, even if the exit is not at the top or bottom of the loop) are not good because the loop is not executed an integral number of times. On the contrary, that is the best possible reason to use a mid-loop exit because many programs do not naturally map to an integral number of iterations. It is always better to allow the control structure map as closely as possible to the problem. So "twisting" a mid-loop exit to make it a top or bottom exit, and possibly duplicating code will make code readability harder. It has also been stated that when multiple exits are allowed, it is necessary for the programmer to actually *read* the code to be able to understand it! Well surprise -- do you really want somebody modifying your code *without* reading it? Sorry, but I don't think so! It also seems to me that this argument has no resolution. Those who are strictly in favor of the orginal, unadulterated structured programming aren't going to give ground to those who favor a more relaxed view of structured programming. 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. Michael Lee Finney