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: Ole-Hjalmar Kristensen Subject: Re: Software landmines (loops) Date: 1998/09/03 Message-ID: #1/1 X-Deja-AN: 387431448 X-NNTP-Posting-Host: fwall.clustra.com Sender: ohk@maestro.clustra.com 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> <6sf87j$47n$1@hirame.wwa.com> <6shp1i$ead$1@nnrp1.dejanews.com> Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada X-Complaints-To: abuse@telia.no Date: 1998-09-03T00:00:00+00:00 List-Id: Phil Goodwin writes: > In article <6sf87j$47n$1@hirame.wwa.com>, > "Robert Martin" wrote: > > > > Matthew Heaney wrote in message ... > > > > > > > >Would the implementation be better by not using multiple returns? > > > > Yes. Imagine that you had to change the function to make it thread safe; > > and that the way to do that was to sieze and release a mutex while the > > function was executing. As written you would have to add the release in > > three separate places. But if you had avoided the multiple returns, you > > would have had a single release. > > Or you could use the Initialization is Resource Aquisition idiom and thereby > choose not to have the problem in the first place, takes care of 'returns' > caused by exceptions as well. > > You could also choose to refactor the code at the time that you are adding > the mutex. First rewrite the routine with a single return and no mutex and > test it to make sure that it still works and then add the mutex and the > single release. > > I write plenty of little routines that have loops in them that exit in the > middle. It doesn't make sense to me to alter the algorithm and write extra > code just so that the routine might be easier to maintain someday (if ever). > On the other hand, when I DO maintain such a routine I definitely WILL make > sure that there is only one exit point if that's what is needed to eliminate > duplicate code. > > I adopted this position in part because of some of what I've read about > Extreme Programming. I haven't adopted it wholesale, but I do like their > no-nonsense philosophy. They use two balancing maxims that I've applied to > this question: Do The Simpest Thing That Could Possibly Work; and Once And > Only Once. So when I write a function I do the simplest thing that could > possibly work, which sometimes means sticking a return right smack in the > middle of a loop. I am especially likely to do this when the loop body is > less than five lines long anyway. Then, when I have to refactor in order to > add the aquisistion and release of some resource, I rearrange the routine so > that I add the code once and only once. The justification for this is that I > don't want to adopt a coding task because it _might_ be needed during > maintenance, I would rather do it during maintenance when I KNOW that it > needs to be done. > > Phil > > -----== Posted via Deja News, The Leader in Internet Discussion ==----- > http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum Yes. Another useful principle is to refactor the code by adding another subroutine which does the aquisition and release, and calls the exixting routine in between. This avoids changing the semantics of the existing routine, which may be desirable.