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: Matthew Heaney <matthew_heaney@acm.org>
Subject: Re: Software landmines (loops)
Date: 1998/09/04
Message-ID: <m3k93k4zgq.fsf@mheaney.ni.net>#1/1
X-Deja-AN: 387733576
Sender: matt@mheaney.ni.net
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@ <904556531.666222@miso.it.uq.edu.au>
 <6sgror$je8$3@news.indigo.ie> <6sh3qn$9p2$1@hirame.wwa.com>
 <Oi4H1.219$qj1.315418@newsread.com> <6simjo$jnh$1@hirame.wwa.com>
 <m3lno372be.fsf@mheaney.ni.net> <6sjk3p$4tc$1@hirame.wwa.com>
 <m34suq7qra.fsf@mheaney.ni.net> <6skgn4$3gq$1@hirame.wwa.com>
 <m3ogsy5che.fsf@mheaney.ni.net> <6sm6md$3fh$1@hirame.wwa.com>
 <6smv8q$cc5$1@nnrp1.dejanews.com>
NNTP-Posting-Date: Thu, 03 Sep 1998 22:07:36 PDT
Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada
Date: 1998-09-04T00:00:00+00:00
List-Id: <comp.lang.ada>

Phil Goodwin<pgoodwin@my-dejanews.com> writes:

> > Matthew Heaney wrote in message ...
> > >My philosophy is, handle the simple case first, then bail out:
> > >
> > >   for (;;)
> > >   {
> > >      Get (N);
> > >
> > >      if (!N) break;
> > >
> > >      <process N>
> > >   }
> >
> > Ask yourself why 'break' is the most important concept of this
> > function?  Why is it more important to get the exceptional conditions
> > out of the way first rather than to get right into the actual purpose
> > of the function.
> 
> You are absolutely right about readability Robert, I read this as "!N
> is a precondition of <process N>. It IS important to know what the
> preconditions of the function are before you get into the actual
> purpose of the function.

Perhaps I should have included a comment that said,

  /* Process a stream of integers.
   * 
   * The stream is terminated by the value 0. 
   */

The problem just easily could have been:

  /* Process a stream of characters.
   *
   * The stream is terminated by the value EOF.
   */
  for (;;) {
     Get (C);

     if (C == EOF) break;

     <process C>
   }

My point is that this is a common kind of problem.  You process a stream
of items, but one of those items is special, and means "no more items
follow."  I argue that the formulation above is the most natural way to
implement this kind of problem.

Researchers showed empirically that using the construction above,
programmers produced fewer errors:

Cognitive Strategies and Looping Constructs: An Empirical Study
Soloway, Bonar, Ehrlich
CACM, Nov 83, Vol 26, No 11, p853-860

As they say, the proof is in the pudding, not the pudding recipe.