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.5 required=5.0 tests=BAYES_00,INVALID_MSGID, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public From: "Robert Martin" Subject: Re: Software landmines (loops) Date: 1998/08/31 Message-ID: <6sf1dn$n52$1@hirame.wwa.com>#1/1 X-Deja-AN: 386549270 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> <35EAB5B1.1DA1986B@ehpt.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-08-31T00:00:00+00:00 List-Id: Mattias Lundstr�m wrote in message <35EAB5B1.1DA1986B@ehpt.com>... 1. Flag solution while( ... && retval == OK ) { ... if( ... ) retval = NOT_OK; } return retval; vs 2. Multiple exits while( ... ) { ... if( ... ) return NOT_OK; } return OK; >(Ie The maintenance argument - that the second code version >becomes harder to read and understand (and thus maintain) - >since the return statement may well not be obvious if there >is a lot of other code within the loop. I do not agree >with this, but it is certainly an argument worth considering. >IMHO This should be covered by good comments where applicable.) It's not so much a matter of being harder to read and understand. Rather it is that there is no good place to make certain kinds of changes to the code. For example, let's say that we had to make a change that forced us to open and close a file that the body of the loop needed to read. Then: 1. Flag solution File* f = fopen(...); while( ... && retval == OK ) { ... if( ... ) retval = NOT_OK; } fclose(f); return retval; vs 2. Multiple exits File* f = fopen(...); while( ... ) { ... if( ... ){ fclose(f); return NOT_OK; } } fclose(f); return OK; Clearly solution 1 is easier to deal with than solution 2. Solution 1 implies that there will be one, and only one, fclose in the function. Whereas solution 2 implies that there will be as many fcloses as there are early returns. And that new fcloses will have to be added if new returns are added. Thus the maintainer must *remember* to add an fclose every time he adds a new return; *and* he must remember to check every return if he adds something else like a fopen/fclose pair in the function (e.g. a malloc/free, a sieze/release, a lock/unlock, etc). So, to reiterate, reading and understanding are not the sole issue. Producing code that is easy to maintain is more to the point. It is quite feasible to have code that you understand perfectly well, but is very hard to maintain. 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