* if-then-no-else Programming
@ 2016-04-19 2:24 Charles H. Sampson
2016-04-19 3:08 ` Dennis Lee Bieber
` (7 more replies)
0 siblings, 8 replies; 17+ messages in thread
From: Charles H. Sampson @ 2016-04-19 2:24 UTC (permalink / raw)
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)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: if-then-no-else Programming
2016-04-19 2:24 if-then-no-else Programming Charles H. Sampson
@ 2016-04-19 3:08 ` Dennis Lee Bieber
2016-04-19 3:19 ` Jeffrey R. Carter
` (6 subsequent siblings)
7 siblings, 0 replies; 17+ messages in thread
From: Dennis Lee Bieber @ 2016-04-19 3:08 UTC (permalink / raw)
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/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: if-then-no-else Programming
2016-04-19 2:24 if-then-no-else Programming Charles H. Sampson
2016-04-19 3:08 ` Dennis Lee Bieber
@ 2016-04-19 3:19 ` Jeffrey R. Carter
2016-04-19 6:18 ` Nasser M. Abbasi
` (5 subsequent siblings)
7 siblings, 0 replies; 17+ messages in thread
From: Jeffrey R. Carter @ 2016-04-19 3:19 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: if-then-no-else Programming
2016-04-19 2:24 if-then-no-else Programming Charles H. Sampson
2016-04-19 3:08 ` Dennis Lee Bieber
2016-04-19 3:19 ` Jeffrey R. Carter
@ 2016-04-19 6:18 ` Nasser M. Abbasi
2016-04-19 7:55 ` Dmitry A. Kazakov
` (4 subsequent siblings)
7 siblings, 0 replies; 17+ messages in thread
From: Nasser M. Abbasi @ 2016-04-19 6:18 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: if-then-no-else Programming
2016-04-19 2:24 if-then-no-else Programming Charles H. Sampson
` (2 preceding siblings ...)
2016-04-19 6:18 ` Nasser M. Abbasi
@ 2016-04-19 7:55 ` Dmitry A. Kazakov
2016-04-19 12:17 ` G.B.
` (3 subsequent siblings)
7 siblings, 0 replies; 17+ messages in thread
From: Dmitry A. Kazakov @ 2016-04-19 7:55 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: if-then-no-else Programming
2016-04-19 2:24 if-then-no-else Programming Charles H. Sampson
` (3 preceding siblings ...)
2016-04-19 7:55 ` Dmitry A. Kazakov
@ 2016-04-19 12:17 ` G.B.
2016-04-20 22:26 ` Martin
2016-04-19 13:27 ` gautier_niouzes
` (2 subsequent siblings)
7 siblings, 1 reply; 17+ messages in thread
From: G.B. @ 2016-04-19 12:17 UTC (permalink / raw)
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, ...
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: if-then-no-else Programming
2016-04-19 2:24 if-then-no-else Programming Charles H. Sampson
` (4 preceding siblings ...)
2016-04-19 12:17 ` G.B.
@ 2016-04-19 13:27 ` gautier_niouzes
2016-04-19 19:51 ` Randy Brukardt
2016-04-19 20:32 ` Charles H. Sampson
7 siblings, 0 replies; 17+ messages in thread
From: gautier_niouzes @ 2016-04-19 13:27 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: if-then-no-else Programming
2016-04-19 2:24 if-then-no-else Programming Charles H. Sampson
` (5 preceding siblings ...)
2016-04-19 13:27 ` gautier_niouzes
@ 2016-04-19 19:51 ` Randy Brukardt
2016-04-19 22:40 ` Shark8
2016-04-20 7:56 ` Charles H. Sampson
2016-04-19 20:32 ` Charles H. Sampson
7 siblings, 2 replies; 17+ messages in thread
From: Randy Brukardt @ 2016-04-19 19:51 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: if-then-no-else Programming
2016-04-19 2:24 if-then-no-else Programming Charles H. Sampson
` (6 preceding siblings ...)
2016-04-19 19:51 ` Randy Brukardt
@ 2016-04-19 20:32 ` Charles H. Sampson
7 siblings, 0 replies; 17+ messages in thread
From: Charles H. Sampson @ 2016-04-19 20:32 UTC (permalink / raw)
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)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: if-then-no-else Programming
2016-04-19 19:51 ` Randy Brukardt
@ 2016-04-19 22:40 ` Shark8
2016-04-20 22:35 ` Randy Brukardt
2016-04-20 7:56 ` Charles H. Sampson
1 sibling, 1 reply; 17+ messages in thread
From: Shark8 @ 2016-04-19 22:40 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: if-then-no-else Programming
2016-04-19 19:51 ` Randy Brukardt
2016-04-19 22:40 ` Shark8
@ 2016-04-20 7:56 ` Charles H. Sampson
2016-04-20 11:26 ` Dennis Lee Bieber
2016-04-20 23:07 ` Jeffrey R. Carter
1 sibling, 2 replies; 17+ messages in thread
From: Charles H. Sampson @ 2016-04-20 7:56 UTC (permalink / raw)
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)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: if-then-no-else Programming
2016-04-20 7:56 ` Charles H. Sampson
@ 2016-04-20 11:26 ` Dennis Lee Bieber
2016-04-20 12:32 ` G.B.
2016-04-20 23:07 ` Jeffrey R. Carter
1 sibling, 1 reply; 17+ messages in thread
From: Dennis Lee Bieber @ 2016-04-20 11:26 UTC (permalink / raw)
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/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: if-then-no-else Programming
2016-04-20 11:26 ` Dennis Lee Bieber
@ 2016-04-20 12:32 ` G.B.
2016-04-20 12:36 ` G.B.
0 siblings, 1 reply; 17+ messages in thread
From: G.B. @ 2016-04-20 12:32 UTC (permalink / raw)
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;
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: if-then-no-else Programming
2016-04-20 12:32 ` G.B.
@ 2016-04-20 12:36 ` G.B.
0 siblings, 0 replies; 17+ messages in thread
From: G.B. @ 2016-04-20 12:36 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: if-then-no-else Programming
2016-04-19 12:17 ` G.B.
@ 2016-04-20 22:26 ` Martin
0 siblings, 0 replies; 17+ messages in thread
From: Martin @ 2016-04-20 22:26 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: if-then-no-else Programming
2016-04-19 22:40 ` Shark8
@ 2016-04-20 22:35 ` Randy Brukardt
0 siblings, 0 replies; 17+ messages in thread
From: Randy Brukardt @ 2016-04-20 22:35 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: if-then-no-else Programming
2016-04-20 7:56 ` Charles H. Sampson
2016-04-20 11:26 ` Dennis Lee Bieber
@ 2016-04-20 23:07 ` Jeffrey R. Carter
1 sibling, 0 replies; 17+ messages in thread
From: Jeffrey R. Carter @ 2016-04-20 23:07 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2016-04-20 23:07 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-19 2:24 if-then-no-else Programming Charles H. Sampson
2016-04-19 3:08 ` Dennis Lee Bieber
2016-04-19 3:19 ` Jeffrey R. Carter
2016-04-19 6:18 ` Nasser M. Abbasi
2016-04-19 7:55 ` Dmitry A. Kazakov
2016-04-19 12:17 ` G.B.
2016-04-20 22:26 ` Martin
2016-04-19 13:27 ` gautier_niouzes
2016-04-19 19:51 ` Randy Brukardt
2016-04-19 22:40 ` Shark8
2016-04-20 22:35 ` Randy Brukardt
2016-04-20 7:56 ` Charles H. Sampson
2016-04-20 11:26 ` Dennis Lee Bieber
2016-04-20 12:32 ` G.B.
2016-04-20 12:36 ` G.B.
2016-04-20 23:07 ` Jeffrey R. Carter
2016-04-19 20:32 ` Charles H. Sampson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox