Re: return statements in procedures

[Ted Dennison <dennison@telepath.com>]

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.