return statements in procedures 
Author Message
 return statements in procedures

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;



Fri, 22 Nov 2002 03:00:00 GMT  
 return statements in procedures

Quote:

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


Fri, 22 Nov 2002 03:00:00 GMT  
 return statements in procedures


Quote:
> 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

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



Fri, 22 Nov 2002 03:00:00 GMT  
 return statements in procedures


Quote:
> 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.

Quote:

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


Fri, 22 Nov 2002 03:00:00 GMT  
 return statements in procedures

Quote:

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



Fri, 22 Nov 2002 03:00:00 GMT  
 return statements in procedures


Quote:
> 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.



Fri, 22 Nov 2002 03:00:00 GMT  
 return statements in procedures

Quote:

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

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



Fri, 22 Nov 2002 03:00:00 GMT  
 return statements in procedures

Quote:

>  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 :-)


Sat, 23 Nov 2002 03:00:00 GMT  
 return statements in procedures

Quote:


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

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



Sat, 23 Nov 2002 03:00:00 GMT  
 return statements in procedures

Quote:

> 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



Sat, 23 Nov 2002 03:00:00 GMT  
 return statements in procedures


Quote:

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

But the Ada language designers are demigods. :-)

--
T.E.D.

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

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



Sat, 23 Nov 2002 03:00:00 GMT  
 return statements in procedures

Quote:

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

  To get back to the original topic, and away from the infalibility of
language
designers, there are several patterns which justify return statements in
procedures.

  The pattern mentioned above should almost be a rule--if one
alternative of a branch
leads to a quick exit, don't use the if then else pattern.  The compiler
may generate
better code, but it makes the ultimate nesting levels shallower, which
is almost always an improvement.

  Another pattern is the search pattern:

    for I in ... loop
      if found then ...; return; end if;
    end loop;
    -- process not found case.

  This pattern is often found in functions, but it also occurs when
inserting into
a list or some other structure.

  The final pattern I am aware of is the same as for the goto.  If you
are implementing
a finite state machine, some case alternatives will return while others
transition to other states.



Sat, 23 Nov 2002 03:00:00 GMT  
 return statements in procedures

Quote:



> > >  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! :-)

Should we start calling you Quigley now?

--
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"



Sat, 23 Nov 2002 03:00:00 GMT  
 return statements in procedures

Quote:

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

Decades of experience with languages such as Pascal that do not have a
return statement have shown that there are many common situations in
which using a return results in code that is easier to read and
understand. Therefore, modern software engineering languages include a
return statement.

The same is true about exiting from the middle of a loop. The one entry
point/one exit point idea came from the world of automated correctness
proofs. If you're doing such proofs, not allowing return statements may
make sense (see for example SPARK). If you're not, then code clarity
should be the guiding factor, and return statements can often improve
code clarity.

"GOTO considered harmful" also came out of the world of proofs, but it
turns out that not using GOTOs as your primary control structure also
improves clarity.

--
Jeff Carter
"I unclog my nose towards you."
Monty python & the Holy Grail



Sat, 23 Nov 2002 03:00:00 GMT  
 return statements in procedures

Quote:

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

Put_Line(%Really?%);  -- 8-)}

Yeah, I know, there were probably good reasons 20 years ago for
allowing '%' as a substitute for '"', but I can't think of any good
reason to use it now.

Quote:
> 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.

The risk here is that later maintenance might add some cleanup code at
the end of the procedure; if the maintainer doesn't notice the return
statement, the cleanup code might be incorrectly skipped in some
cases.

The real lesson of course, is that maintenance programmers need to pay
attention to the code they're working on, and if the control flow in a
single procedure becomes too complex it's probably time to think about
redesigning it.

I agree that return statements in procedures, when used carefully, can
be A Good Thing -- just like (almost) any other language feature.

--

San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.



Sat, 23 Nov 2002 03:00:00 GMT  
 
 [ 19 post ]  Go to page: [1] [2]

 Relevant Pages 

1. should read of procedure return a procedure ?

2. procedure + wait statement

3. Synthesize WAIT-statement in procedure

4. wait statement in procedures

5. DB2 statements in Working or Procedure

6. Q: Dummy procedures and the f2k IMPORT statement?

7. procedure as dummy argument (was: EXTERNAL and INTRINSIC statement)

8. Interesting new iteration procedure / control statement

9. PROCEDURE statement order question

10. Help: forcing a statement in a procedure

11. Implemented warning about inconsistent usage of return statements

12. Return code of 1 from a RXFuncAdd statement.

 

 
Powered by phpBB® Forum Software