Re: return statements in procedures

Re: return statements in procedures

[r_c_chapman]

In article <393B2054.618F6E80@baesystems.com.au>,
  Matthew Daniel <matthew.daniel@baesystems.com.au> wrote:
> Hi,
>
> we are having a "discussion" at work at the moment about return
> statements in procedures.

For what's it worth, they're not allowed in SPARK, and I don't
really miss them.  I can only think of one or two occasions in the
last 5 years when I've really needed such a thing.  The restricitons
on return statements in SPARK are such that subprograms always
have a single-entry/single-exit flow graph, which makes
subsequent Flow Analysis and Verificaiton Condition Generation
much easier..
 - Rod Chapman
   SPARK Team, Praxis Critical Systems, rod@praxis-cs.co.uk



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: return statements in procedures

[Robert Dewar]

In article <393B2054.618F6E80@baesystems.com.au>,
  Matthew Daniel <matthew.daniel@baesystems.com.au> wrote:
> Hi,
>
> we are having a "discussion" at work at the moment about
return
> statements in procedures.
>
> There is one who believes it is acceptable for certain
> circumstances and the rest of us do not believe it should
> occur.

The "one" is to be commended. Any time you decide that a feature
in Ada should never ever be used, you are almost certainly
making a mistake. If that was really the case, the feature
would not be in the language to start with.

In the case of return, it definitely can be advantageous to
use this construct and can often make code far easier to read.

For example if deep in a list of nested if's I see

    if ..... then
       Record_No_Good;
       Result := No_Good;
       return;
    end if;

I know immediately that processing is complete at the point of
the return. I do not have to unwind through the nested if's to
see if any more processing remains to be done.

Another common case is
right at the start of the procedure

   if .... then
      return;
   end if;

immediately indicating cases where the procedure does nothing
and getting rid of them from the mind of the reader. That's
usually better than enclosing the entire rest of the procedure
one level down in an else.

The rule is simple. Use return when it makes things clearer
to read.






>
> just seeing what every one else thinks.
>
> Matt
>
> eg
>
> procedure Blah (....) is
>
> begin
>
>   if .... then
>      return;
>   end if;
>   ..
> end Blah;
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: return statements in procedures

[Robert Dewar]

In article <8hfujg$nl5$1@nnrp1.deja.com>,
  r_c_chapman@my-deja.com wrote:
> The restricitons
> on return statements in SPARK are such that subprograms always
> have a single-entry/single-exit flow graph, which makes
> subsequent Flow Analysis and Verificaiton Condition Generation
> much easier..


Fair enough, but this is at the expense of human readability.
Yes, in SPARK that tradeoff often makes sense, many of the
restrictions in SPARK result in programs that are harder to
read for a human, but we have different objectives in mind
in this context :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: return statements in procedures

[Ted Dennison]

In article <393B2054.618F6E80@baesystems.com.au>,
  Matthew Daniel <matthew.daniel@baesystems.com.au> wrote:

> we are having a "discussion" at work at the moment about return
> statements in procedures.
>
> There is one who believes it is acceptable for certain circumstances
> and the rest of us do not believe it should occur.


Personally, I have no compunction about doing that where I believe it
would make the code simpler and easier to understand. Sorting and
searching are the most common examples.

Answer me this: If lack of a "return" causes developers to have to add
extra flags and convoluted (and CPU-consuming) control logic, what
exactly have you gained for this trade-off?

I once worked on a DoD INFOSEC job where we had a requirement for no
more than one exit path out of any subroutine. My cubemate was shocked
when he saw that I put a "return" in a procedure, but the "return" was
the only logical (non-exceptional) path out of the procedure, so it was
perfectly kosher with our customer. :-)

Note that if you *do* restrict that keyword, you should also consider
forbiding exceptions in procedures. They allow roughly the same thing,
and some developers (particularly your "one") are bound to use them to
get around that annoying restriction.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

return statements in procedures

[Matthew Daniel]

Hi,

we are having a "discussion" at work at the moment about return
statements in procedures.

There is one who believes it is acceptable for certain circumstances and
the rest of us do not believe it should occur.

just seeing what every one else thinks.

Matt

eg 

procedure Blah (....) is

begin

  if .... then
     return;
  end if;
  ..
end Blah;

Re: return statements in procedures

[Geoff Bull]

Matthew Daniel wrote:
> 
> There is one who believes it is acceptable for certain circumstances and
> the rest of us do not believe it should occur.
> 
> just seeing what every one else thinks.

Given appropriate circumstances, anything is acceptable.
If return statements in procedures were never acceptable,
the language designers would have made them illegal.

Re: return statements in procedures

[Marin D. Condic]

Matthew Daniel wrote:
> procedure Blah (....) is
> 
> begin
> 
>   if .... then
>      return;
>   end if;
>   ..
> end Blah;

While you might want to question the design of a procedure that had some
large number of "return" statements scattered throughout it, I don't see
what makes one or more "return" statements inherently evil. I think some
folks fear it because of an almost slavish devotion to the "No Goto's"
rule. (BTW, I've been programming in Ada for over 15 years and never
once used a goto for anything other than illustration purposes. Not that
I fear them - just never had much use for one. ;-)

That said, I have used the "return" statement in procedures on a number
of occasions where I may be doing some kind of immediate validity check
up front and want to quit rather than go through the rest of the code,
or when you get into checking lots of conditions (nested "if"
situations) and you've determined that the branch you're on means its
time to quit. Judicious use of the "return" statement can make it easier
to understand the code. Avoiding it at all cost can lead to some
butt-ugly convolutions that are harder to understand.

My vote would be to go ahead and do it, but always ask if it is making
things better or if it is an indication that the design is flawed. (Are
you asking the procedure to do too much? Is there a simpler way to
implement the requirements?)

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"Some people think programming Windows is like nailing jello to the 
ceiling... easy with the right kind of nails."

    --  Ivor Horton - Beginning Visual C++ 6
======================================================================

Re: return statements in procedures

[Robert A Duff]

Geoff Bull <geoff@research.canon.com.au> writes:

> Given appropriate circumstances, anything is acceptable.
> If return statements in procedures were never acceptable,
> the language designers would have made them illegal.

That doesn't follow -- language designers are not gods.

- Bob

Re: return statements in procedures

[Geoff Bull]

"Marin D. Condic" wrote:
>  I've been programming in Ada for over 15 years and never
> once used a goto for anything other than illustration purposes. Not that
> I fear them - just never had much use for one.

I find goto's very useful for avoiding the use of
return statements in procedures :-)

Re: return statements in procedures

[Marin D. Condic]

Geoff Bull wrote:
> 
> "Marin D. Condic" wrote:
> >  I've been programming in Ada for over 15 years and never
> > once used a goto for anything other than illustration purposes. Not that
> > I fear them - just never had much use for one.
> 
> I find goto's very useful for avoiding the use of
> return statements in procedures :-)

Said I never had much use for one. Didn't say I didn't know how to use
it! :-)

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"Some people think programming Windows is like nailing jello to the 
ceiling... easy with the right kind of nails."

    --  Ivor Horton - Beginning Visual C++ 6
======================================================================