Re: if-then-no-else Programming

["Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>]

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