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: 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: Biju Thomas <bijuthom@ibm.net>
Subject: Re: Software landmines (loops)
Date: 1998/09/01
Message-ID: <35EC91EB.BEF1DB23@ibm.net>#1/1
X-Deja-AN: 386963398
Content-Transfer-Encoding: 7bit
References: <slrn6sopmg.4fg.jdege@jdege.visi.com>
 <rfzpddz3s2.fsf@bnp-eng.remcomp.com>
 <902934874.2099.0.nnrp-10.c246a717@news.demon.co.uk> <dewar.903074236@merv>
 <6r1glm$bvh$1@nnrp1.dejanews.com> <dewar.903281994@merv>
 <6r9f8h$jtm$1@nnrp1.dejanews.com> <6renh8$ga7$1@nnrp1.dejanews.com>
 <6rf59b$2ud$1@nnrp1.dejanews.com> <l5HC1.6840$wN.1856764@news.giganews.com>
 <6rfra4$rul$1@nnrp1.dejanews.com> <35DBDD24.D003404D@calfp.co.uk>
 <m3ogt3qgca.fsf@mheaney.ni.net> <6sbuod$fra$1@hirame.wwa.com>
 <35f51e53.48044143@ <m3af4mq7f4.fsf@mheaney.ni.net>
 <904556531.666222@miso.it.uq.edu.au> <m31zpxqutn.fsf@mheaney.ni.net>
 <6sf87j$47n$1@hirame.wwa.com> <35EC3440.9FA81BF1@west.raytheon.com>
 <6shhg4$llp$1@hirame.wwa.com>
X-Notice: should be reported to postmaster@ibm.net
Content-Type: text/plain; charset=x-user-defined
X-Complaints-To: postmaster@ibm.net
X-Trace: 2 Sep 1998 00:31:07 GMT, 129.37.231.109
Organization: IBM.NET
MIME-Version: 1.0
Reply-To: bijuthom@ibm.net
Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada
Date: 1998-09-01T00:00:00+00:00
List-Id: <comp.lang.ada>

Robert Martin wrote:
> 
> Chris Brand wrote in message <35EC3440.9FA81BF1@west.raytheon.com>...
> >Robert Martin wrote:
> >>
> >> bool operator==(Stack& l, Stack& r)
> >> {
> >>   bool equal = true;
> >>   for (int index = 1; index < l.top() && equal == true; index++)
> >>   {
> >>     if (l[index] != r[index])
> >>       equal = false;
> >>   }
> >>   return equal;
> >> }
> >>
> >> If this is more complex (something that is arguable) it is not *much*
> more
> >> complex.  On the other hand, it is easier to maintain.
> >
> >It is open to (maintenance) errors such as
> >   for (int index = 1; index < l.top() && equal = true; index++)
> >which the multiple-return version isn't, so the "easier to maintain"
> >argument is far from clear-cut.
> 
> I think *all* structures are vulnerable to typos.  The code above is no more
> vulnerable than any other code is.

If it was
1)
   for (int index = 1; index < l.top() && equal; index++)

or
2)
   for (int index = 1; index < l.top() && true == equal; index++)

it might not have been vulnerable to this type of typos (which is
frequent in C++, I think).

Of course, some people say the second style is less readable. But the
the first one seems to be best.

Biju Thomas