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!.POSTED!not-for-mail
From: "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>
Newsgroups: comp.lang.ada
Subject: Re: if-then-no-else Programming
Date: Mon, 18 Apr 2016 20:19:48 -0700
Organization: Also freenews.netfront.net; news.tornevall.net;
 news.eternal-september.org
Message-ID: <nf47ua$m5c$1@dont-email.me>
References: <1mlx1gf.ebrae11jak5tyN%csampson@inetworld.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 19 Apr 2016 03:16:28 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="48b46be33beed75863f69afa437f956b";
	logging-data="22700"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+1e6hiB9qg7J/ucdOCp2Si3q4MXrFUPq8="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.0
In-Reply-To: <1mlx1gf.ebrae11jak5tyN%csampson@inetworld.net>
Cancel-Lock: sha1:uxn2pluaPTJ2kCCZWTsVkf/wyMk=
Xref: news.eternal-september.org comp.lang.ada:30183
Date: 2016-04-18T20:19:48-07:00
List-Id: <comp.lang.ada>

On 04/18/2016 07:24 PM, Charles H. Sampson wrote:
>
> 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:
>
>    Variable := 3;
>    if <condtion> then
>       Variable := 1;
>    end if;
>
> In addition to some other goodness attributes, this is supposed to be
> clearer than the if-then-else form.
>
> Is he right? (He's not really a coder. His experience is in wire-frame
> animation but he's being forced into coding by the job market.) If he's
> not right, have any of you even heard of an area of the software
> "profession" where this position is held?

Of course not. If the else part has (side) effects that must not happen unless 
the condition is False, this form is clearly unacceptable

Set_Throttle (Percent_Of_Full => 100.0);

if Desired_Speed >= Speed_Limit then
    Set_Throttle (Percent_Of_Full => Level_To_Maintain (Speed_Limit) );
end if;

This style was common in FORTRAN-66 programming (my 1st language), which had no 
structured IF statement

      V=3
      IF(C)V=1

because it was considered more efficient than the F66 equivalents of if-else

      IF(C)V=1
      IF(.NOT.C)V=3

or

      IF(.NOT.C)GOTO 100
      V=1
      GOTO 110
100  V=3
110  CONTINUE

Of course, the efficiency difference was rarely worth considering. This is 
discussed by Kernighan & Plauger in /Software Tools/ (1976) about the efficiency 
of the code produced by the Ratfor to FORTRAN translator:

"By now you are no doubt squirming over the inefficiency of this translation. 
There are goto's that go to a goto; there are multiple tests like

      if (col .gt. MAXLINE) tabpos = YES
      if (col .le. MAXLINE) tabpos = tabs(col)

instead of the Fortran idiom

      tabpos = YES
      if (col .le. MAXLINE) tabpos = tabs(col)

... Branching to branches, and the multiple tests in tabpos and settab are also 
irrelevant. Their effect on running time is so minuscule that we could not 
detect it."

If I had to, I'd guess this idea has resurfaced in a language where it's 
considered a good idea to minimize typing. It avoids having to type "else" and 
maybe a couple of braces.

On the other hand, when the if statement always returns or raises an exception, 
it's usually clearer to omit the else part:

if Condition then
    Do (Result => Result);
    Some (Result => Result);
    Stuff (Result => Result);

    return Result;
end if;

Do (Result => Result);
Some (Result => Result);
Other (Result => Result);
Stuff;

return Result;

rather than

if Condition then
    Do (Result => Result);
    Some (Result => Result);
    Stuff (Result => Result);

    return Result;
else
    Do (Result => Result);
    Some (Result => Result);
    Other (Result => Result);
    Stuff;

    return Result;
end if;

-- 
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail
17