if-then-no-else Programming

if-then-no-else Programming

[Charles H. Sampson]

It's hard to believe that it's been over six years since I wrote a line
of code for profit. If what my son tells me, there's been what I
consider a major change in software engineering during that time.

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?

Charlie
-- 
Nobody in this country got rich on his own.  You built a factory--good.
But you moved your goods on roads we all paid for.  You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward.  Elizabeth Warren (paraphrased)

Re: if-then-no-else Programming

[Dennis Lee Bieber]

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/

Re: if-then-no-else Programming

[Jeffrey R. Carter]

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

Re: if-then-no-else Programming

[Nasser M. Abbasi]

On 4/18/2016 9:24 PM, Charles H. Sampson wrote:

>
>     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?
>

The above is very confusing way to code. I would not recommened it.

Re: if-then-no-else Programming

[Dmitry A. Kazakov]

On 19/04/2016 04:24, Charles H. Sampson wrote:
> It's hard to believe that it's been over six years since I wrote a line
> of code for profit. If what my son tells me, there's been what I
> consider a major change in software engineering during that time.
>
> 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?

There are only few cases when asymmetric if-then is ever used.

1. Initialized default

    Variable : Integer := 3;
begin
    ...
    if <condition> then
       Variable := 1;
    end if;

Similar case is bulk initialization of arrays:

    Variable : String (1..80) := (others => ' ');
begin
    ...
    if <condition> then
       Variable (20) := 'a';
    end if;

2. Unbalanced terminating alternative. When THEN is very short and 
terminates some execution control path:

procedure Foo (Variable : out Integer) is
begin
    ...
    if <condition> then
       Variable := 1;
       return;
    end if;
    ... -- Do a lot of stuff
end Foo;

It could be "raise" instead of return, or "exit" when the variable is 
set as the result of a loop execution.

Otherwise, the advice is evident rubbish, as others have pointed out 
already.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: if-then-no-else Programming

[G.B.]

On 19.04.16 04:24, 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;

I think that "software engineering" here might mean web development
or media development; not the typical areas of engineering, AFAIK.
But while speculation, this really seems to about making sure that
variables have a value assigned, not so much about conditionals
per se.

If about guaranteed assignment, then languages have started
supporting the initialization problem in much better ways.
The above example reminds me of PHP/Python/Javascript, etc.
Swift, OTOH, a newly developed language, guarantees assignment
before use and rejects, as do some older language for constants,
this definition:

     func foo(condition: Bool) {
         var Variable : Int

         if condition {
             Variable = 1
         }
         bar(Variable)
NN:error:   ^ variable 'Variable' used before being initialized
     }


GNAT has a similar warning. Is there still a reason why,
in embedded system, assignment is considered costly, maybe,
and thus had better be done only as necessary, instead
of being enforced, using default values, or dummy values?
Or even constructor invocations?

Ada 2012 adds conditional expressions (in addition to the
old nested functions that need to return). So, if the value
that is to be assigned depends on Condition,

    Variable :=
     (if Condition
       then 1
       else 3);

is another way of making sure that Variable is initialized,
in *one* statement!

This expression is part of many languages, albeit using
different syntax. The list includes Python, Javascript, C, ...

Re: if-then-no-else Programming

[Martin]

On Tuesday, April 19, 2016 at 1:17:18 PM UTC+1, G.B. wrote:
[snip]
> Ada 2012 adds conditional expressions (in addition to the
> old nested functions that need to return). So, if the value
> that is to be assigned depends on Condition,
> 
>     Variable :=
>      (if Condition
>        then 1
>        else 3);
> 
> is another way of making sure that Variable is initialized,
> in *one* statement!
[snip]

I *much* prefer this style as the post-condition can't be accidentally missed (the post-condition being that 'Variable' is assigned a value). Leave 'if' statements for doing genuinely different responses.

-- Martin

Re: if-then-no-else Programming

[gautier_niouzes]

Wait a bit and the next fad will be again functional programming where variables must be avoided...
_________________________ 
Gautier's Ada programming 
http://www.openhub.net/accounts/gautier_bd

Re: if-then-no-else Programming

[Randy Brukardt]

"Charles H. Sampson" <csampson@inetworld.net> wrote in message 
news:1mlx1gf.ebrae11jak5tyN%csampson@inetworld.net...
> It's hard to believe that it's been over six years since I wrote a line
> of code for profit. If what my son tells me, there's been what I
> consider a major change in software engineering during that time.
>
> 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?

This sounds like nonsense to me. It wouldn't make sense for the majority of 
the code that we have:

    if condition then
        Do_It;
    else -- Can't get here.
        Internal_Error ("Impossible branch");
    end if;

and

    if Is_Float (Expr.Typ) then
        Generate_Float_Code (Expr.Typ);
   else
        Generate_Integer_Code (Expr.Typ);
   end if;

I think if we generated both kinds of code for a float expression, we 
wouldn't have been in the compiler business for long. ;-)

Indeed, RRS has a style rule which is the exact opposite of his suggestion. 
We require either an else or a comment that no else is needed for most if 
statements. We found that we had cases like:

    if condition then
         Do_Something;
    end if;

and there would be a bug because nothing was done if condition was False. 
Errors of omission are the hardest things to find, and we hoped to reduce 
the number of them by at least requiring the programmer to think about all 
of the possibilities and documenting that they did so. Thus, the above would 
have to be written:

    if condition then
         Do_Something;
    -- else nothing needed.
    end if;

so it's obvious that the reverse condition was considered.

There are of course cases where the suggested form would work, but even in 
those one needs to document that the else was omitted on purpose and not 
just forgotten. Otherwise, a future maintainer has to guess which case is 
involved and that can cause one to waste a lot of time on things that are 
intended.

                               Randy.

Re: if-then-no-else Programming

[Shark8]

On Tuesday, April 19, 2016 at 1:51:07 PM UTC-6, Randy Brukardt wrote:
> 
> Indeed, RRS has a style rule which is the exact opposite of his suggestion. 
> We require either an else or a comment that no else is needed for most if 
> statements. We found that we had cases like:
> 
>     if condition then
>          Do_Something;
>     end if;
> 
> and there would be a bug because nothing was done if condition was False. 
> Errors of omission are the hardest things to find, and we hoped to reduce 
> the number of them by at least requiring the programmer to think about all 
> of the possibilities and documenting that they did so. Thus, the above would 
> have to be written:
> 
>     if condition then
>          Do_Something;
>     -- else nothing needed.
>     end if;
> 
> so it's obvious that the reverse condition was considered.

But we can do this natively in Ada:

if condition then
  Do_Something;
else
  null; -- Nothing needed.
end if;

I would think that there would be zero difference in code generation between that and w/o the else.

Re: if-then-no-else Programming

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:8328e4e6-97b7-49b6-92de-9f60181dc563@googlegroups.com...
> On Tuesday, April 19, 2016 at 1:51:07 PM UTC-6, Randy Brukardt wrote:
...
>> and there would be a bug because nothing was done if condition was False.
>> Errors of omission are the hardest things to find, and we hoped to reduce
>> the number of them by at least requiring the programmer to think about 
>> all
>> of the possibilities and documenting that they did so. Thus, the above 
>> would
>> have to be written:
>>
>>     if condition then
>>          Do_Something;
>>     -- else nothing needed.
>>     end if;
>>
>> so it's obvious that the reverse condition was considered.
>
> But we can do this natively in Ada:
>
> if condition then
>  Do_Something;
> else
>  null; -- Nothing needed.
> end if;
>
> I would think that there would be zero difference in code generation 
> between that and w/o the else.

Sure, you could just require the "else". But for us, the comment is the 
important part, and the need to include an extra line can make the code 
harder to read (especially when we adopted this rule, as editors typically 
could only show 24 lines at a time). Thus we adopted an "else or comment 
starting with else" rule.

                                    Randy.

Re: if-then-no-else Programming

[Charles H. Sampson]

Randy Brukardt <randy@rrsoftware.com> wrote:

> "Charles H. Sampson" <csampson@inetworld.net> wrote in message 
> news:1mlx1gf.ebrae11jak5tyN%csampson@inetworld.net...
> > It's hard to believe that it's been over six years since I wrote a line
> > of code for profit. If what my son tells me, there's been what I
> > consider a major change in software engineering during that time.
> >
> > 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?
> 
> This sounds like nonsense to me. It wouldn't make sense for the majority of
> the code that we have:
> 
>     if condition then
>         Do_It;
>     else -- Can't get here.
>         Internal_Error ("Impossible branch");
>     end if;
> 
> and
> 
>     if Is_Float (Expr.Typ) then
>         Generate_Float_Code (Expr.Typ);
>    else
>         Generate_Integer_Code (Expr.Typ);
>    end if;
> 
> I think if we generated both kinds of code for a float expression, we
> wouldn't have been in the compiler business for long. ;-)
> 
> Indeed, RRS has a style rule which is the exact opposite of his suggestion.
> We require either an else or a comment that no else is needed for most if
> statements. We found that we had cases like:
> 
>     if condition then
>          Do_Something;
>     end if;
> 
> and there would be a bug because nothing was done if condition was False.
> Errors of omission are the hardest things to find, and we hoped to reduce
> the number of them by at least requiring the programmer to think about all
> of the possibilities and documenting that they did so. Thus, the above would
> have to be written:
> 
>     if condition then
>          Do_Something;
>     -- else nothing needed.
>     end if;
> 
> so it's obvious that the reverse condition was considered.
> 
> There are of course cases where the suggested form would work, but even in
> those one needs to document that the else was omitted on purpose and not
> just forgotten. Otherwise, a future maintainer has to guess which case is
> involved and that can cause one to waste a lot of time on things that are
> intended.

Don't hold me to this, but I have this vague memory that somewhere back
at the beginning of Ada there was a proposal that every if-statement had
to have an else-statement. I don't remember if it was one of the early
incarnations of Ada, somebody's proposed coding style, on one of the
non-green language proposals.

The point was to indicate in the code that the possibility of the
if-condition's being false had been considered.

Charlie
-- 
Nobody in this country got rich on his own.  You built a factory--good.
But you moved your goods on roads we all paid for.  You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward.  Elizabeth Warren (paraphrased)

Re: if-then-no-else Programming

[Dennis Lee Bieber]

On Wed, 20 Apr 2016 00:56:39 -0700, csampson@inetworld.net (Charles H.
Sampson) declaimed the following:

>
>Don't hold me to this, but I have this vague memory that somewhere back
>at the beginning of Ada there was a proposal that every if-statement had
>to have an else-statement. I don't remember if it was one of the early
>incarnations of Ada, somebody's proposed coding style, on one of the
>non-green language proposals.
>

	Sounds like a coding style conducive to certification of
safety-critical software.

	Of course, it then contends with the other aspect of removing dead code
(unless it can be demonstrated that the compiler always optimizes away the
Null branch). <G>

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

Re: if-then-no-else Programming

[G.B.]

On 20.04.16 13:26, Dennis Lee Bieber wrote:

> 	Of course, it then contends with the other aspect of removing dead code
> (unless it can be demonstrated that the compiler always optimizes away the
> Null branch). <G>

Removing null branches might need justification in the
first place because both programmers and compilers might
be aware of the benefits that controlling processors'
activities in instruction pipelines might entail.
Disassembling today's programs reveals a fair amount of
instructions.

Perhaps, then, Ada should have an aspect for this,

    else
        null with Volatile;
    end if;

Re: if-then-no-else Programming

[G.B.]

On 20.04.16 14:32, G.B. wrote:
> Disassembling today's programs reveals a fair amount of
> instructions.

A "null" has been edited out in the above sentence.
Before instructions. Darn.

Re: if-then-no-else Programming

[Jeffrey R. Carter]

On 04/20/2016 12:56 AM, Charles H. Sampson wrote:
>
> Don't hold me to this, but I have this vague memory that somewhere back
> at the beginning of Ada there was a proposal that every if-statement had
> to have an else-statement. I don't remember if it was one of the early
> incarnations of Ada, somebody's proposed coding style, on one of the
> non-green language proposals.
>
> The point was to indicate in the code that the possibility of the
> if-condition's being false had been considered.

I don't require it for a simple if statement, but I use the rule that an if with 
an elsif must have an else. This shows that all alternatives have been 
considered. If the else part is null, it provides a convenient place for the 
comment explaining why no action is needed.

-- 
Jeff Carter
"[M]any were collected near them, ... to
enjoy the sight of a dead young lady, nay,
two dead young ladies, for it proved twice
as fine as the first report."
Persuasion
155

Re: if-then-no-else Programming

[Charles H. Sampson]

Charles H. Sampson <csampson@inetworld.net> wrote:

> It's hard to believe that it's been over six years since I wrote a line
> of code for profit. If what my son tells me, there's been what I
> consider a major change in software engineering during that time.
> 
> 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?

Thanks to all who applied. Everybody seems to be as appalled as I am
about this idea. And you came up with one or two negative impacts that I
hadn't thought of yet.

Charlie
-- 
Nobody in this country got rich on his own.  You built a factory--good.
But you moved your goods on roads we all paid for.  You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward.  Elizabeth Warren (paraphrased)