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: f43e6,9a0ff0bffdf63657
X-Google-Attributes: gidf43e6,public
X-Google-Thread: 103376,4b06f8f15f01a568
X-Google-Attributes: gid103376,public
X-Google-Thread: 1108a1,9a0ff0bffdf63657
X-Google-Attributes: gid1108a1,public
X-Google-Thread: fac41,9a0ff0bffdf63657
X-Google-Attributes: gidfac41,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Software landmines (loops)
Date: 1998/09/01
Message-ID: <EACHUS.98Sep1183212@spectre.mitre.org>#1/1
X-Deja-AN: 386937027
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> <35EAB5B1.1DA1986B@ehpt.com>
 <6sf1dn$n52$1@hirame.wwa.com> <35EB9B91.3FF8583@ehpt.com>
 <6sh2rp$8v3$1@hirame.wwa.com>
Organization: The Mitre Corp., Bedford, MA.
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>

In article <6sh2rp$8v3$1@hirame.wwa.com> "Robert Martin" <rmartin@oma.com> writes:

 > Now certainly it is easier to write the functions with multiple exits.  And
 > if the functions never change, then you have won; and using a structured
 > programming approach would be a net loss.  However, functions generally
 > don't remain the same.  Most of the time they <<grow>> (remember Kahn
 > talking about how his "pets" enter through your ear and live inside your
 > brain?  "Later", he said, " as they <<grow>>...") Functions that have not
 > been built using structured programming can degrade pretty badly when they
 > <<grow>>.

   (First some flame retardant, hopefully unnecessary.  What follows
talks about how the difference in paradigms between Ada and other
languages affect which style--multiple exit--Ada programmers prefer.
That doesn't mean that Ada is better, even though it is. ;-)

    Ada programmers are not used to functions growing.  An abstraction
is written once, then used forever.  If it needs to be extended, you
derive from it (called subtyping or subclassing in other OO languages),
or extend the type locally with locally declared subprograms.
Modifying existing code is a very rare process, and it usually
involves changes, not growth.  Package specs often grow during
development, but that is usually due to recognizing the need or
potential need for some additional operation to be exported.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...