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.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!Xl.tags.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 18 Apr 2016 22:08:14 -0500
From: Dennis Lee Bieber <wlfraed@ix.netcom.com>
Newsgroups: comp.lang.ada
Subject: Re: if-then-no-else  Programming
Date: Mon, 18 Apr 2016 23:08:16 -0400
Organization: IISS Elusive Unicorn
Message-ID: <in7bhb1s19fvukublmpqo3fs79nqq46qg0@4ax.com>
References: <1mlx1gf.ebrae11jak5tyN%csampson@inetworld.net>
X-Newsreader: Forte Agent 6.00/32.1186
X-No-Archive: YES
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 108.68.176.206
X-Trace: 
 sv3-pRdwEvsSHyZp8c79c6PpRqNyGlOb8Or8lTVyP50b3Z+HKZiDE50pO5WqsSPJ1ad3/cCj6JSQScNYuv4!JRM294X9aDt9a3wfTKe0zArirjCFloIeH/JmKTe3MTufrFXH+Hfncg0EP2oVzY/soPoWtzD2jARr!cSu4tXmz1qIJVU7xrY9Hw4QKpceJ
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint
 properly
X-Postfilter: 1.3.40
X-Original-Bytes: 2531
Xref: news.eternal-september.org comp.lang.ada:30182
Date: 2016-04-18T23:08:16-04:00
List-Id: <comp.lang.ada>

On Mon, 18 Apr 2016 19:24:51 -0700, csampson@inetworld.net (Charles H.
Sampson) declaimed the following:

>
>He says that there's a move to ban the use of the else-statement. The
>preferred approach is to execute the else-part first, then change the
>effect if the if-condition is satisfied. For example:
>
	A "move" where?

>   Variable := 3;
>   if <condtion> then
>      Variable := 1;
>   end if;
>

	Sure wouldn't work anywhere where the alternatives have side-effects

	if New_Record then
		Insert_Record(data);
	else
		Replace_Record(data);
	end if;

vs

	Replace_Record(data):	-- what if there isn't a record?
	if New_Record then
		Insert_Record(data);
	end if;


	And probably is not recommended if (for simple assignment) the target
is a volatile object -- like GPIO pins accessed via a mapped register. One
wouldn't want to trigger some state that isn't really valid.

	if not Walk then
		Walk_Signal = value_of_dont_walk_lights;
	else
		Walk_Signal = value_of_walk_lights;
	end if;

vs

	Walk_Signal = value_of_walk_lights;
	if not Walk then
		Walk_Signal = value_of_dont_walk_lights;
	end if;

	Would you really want the cross-walk lights to flicker "walk" when
determining they should be "don't walk"? {Yes, it's an artifical example,
but still...}
	

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/