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: duncan@yc.estec.esa.nlx
Subject: Re: Software landmines (loops)
Date: 1998/09/08
Message-ID: <Eyz1vB.EoC@yc.estec.esa.nl>#1/1
X-Deja-AN: 389061197
Sender: duncan@yc.estec.esa.nlx
References: <35F534F6.D3CCE360@sprintmail.com>
Organization: ESA/ESTEC/YC, Noordwijk, The Netherlands
Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada
Date: 1998-09-08T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <35F534F6.D3CCE360@sprintmail.com>,
John G. Volan <johnvolan@sprintmail.com> wrote:
>
> [... transformed heavily indented nested if's to single level of
> indentation by effectively NOTing the test condition and adjusting
> the formatting ...]
>
>As you can see, the nesting has been considerably reduced, yet this
>function is still single entry/single exit.  It also shares with the
>early-return version the advantage of showing the choice of error-code
>close to the test that determines the error.
>
>Best of both worlds? :-)

Yes, but this was my point. Many people rail against early returns
as being "problematic" for whatever reason or purpose. To my mind,
provided you restrict early returns to 'pre-condition checking', the
logic can still be preserved, and can be just as "readable" (or indeed
"unreadable") as a se/se solution. [*]

If you sprinkle return statements in the middle of the inner gubbins
of the routine where resources have been allocated, or modified, or
waiting to be reallocated, then it is much more difficult to ensure
that each early return actually leaves the system in an appropriate
state. This is especially true when the maintenance/upgrade phase
begins when nobody remembers all of the gotchas any more.

[*] Note that sometimes the natural flow of one form of a test can make
it a lot easier to understand what is going on than choosing the negative
form of the test just to fit with a particular style. This can also
influence which form you would use. Unfortunately no examples of this
spring to mind other than:

	if (IsX(a))
	{
		ProcessX(a);
	} else
	if (IsY(a))
	{
		ProcessY(a);
	} else
	{
		ProcessZ(a);
	}

as opposed to

	if (!IsX(a))
	{
		if (!IsY(a))
		{
			ProcessZ(a);
		} else
		{
			ProcessY(a);
		}
	} else
	{
		ProcessX(a);
	}

And as has been already noted, what is "readable" or "unreadable" is
very subjective.

This is my article, not my employer's, with my opinions and my disclaimer!
--
Duncan Gibson, ESTEC/YCV, Postbus 299, 2200AG Noordwijk, The Netherlands
Tel: +31 71 5654013   Fax: +31 71 5656142  Email: duncan@yc.estec.esa.nlx
To avoid junk email my quoted address is incorrect. Use nl instead of nlx.