Return statements and their scope - guideline

Return statements and their scope - guideline

[Maciej Sobczak]

Hi,

I have found a coding guideline that allows return statements only in 
the outermost scope in the subprogram - which is supposed to avoid 
obscuring the control flow.

What is outermost scope in this context?

function F return Integer is
begin
   if Some_Condition then
      return 0;   -- (1)
   end if;
   -- ...
   declare
     X : Integer;
   begin
     -- ...
     return X;    -- (2)
   end;
   -- ...
   return 7;      -- (3)
end F;

Is (1) above in the outermost scope?
I understand that (2) is not (and is therefore discouraged) and (3) is 
definitely in the outermost scope, but (1) is not very obvious.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Return statements and their scope - guideline

[Jeffrey R. Carter]

Maciej Sobczak wrote:
> 
> I have found a coding guideline that allows return statements only in 
> the outermost scope in the subprogram - which is supposed to avoid 
> obscuring the control flow.
> 
> What is outermost scope in this context?
> 
> function F return Integer is
> begin
>   if Some_Condition then
>      return 0;   -- (1)
>   end if;
>   -- ...
>   declare
>     X : Integer;
>   begin
>     -- ...
>     return X;    -- (2)
>   end;
>   -- ...
>   return 7;      -- (3)
> end F;
> 
> Is (1) above in the outermost scope?

No. This is the rule in SPARK: You have to write

if Some_Condition then
    Result := 0;
else
    ...
    Result := ...;
end if;

return Result;

This makes the analysis easier. However, I've always felt

if Some_Condition then
    return 0;
end if;

is easier to read; if you're interested in the case where Some_Condition 
holds, then you don't have to read any further.

I wonder how such coding standards will deal with the extended return 
statement of Ada 0X.

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail
03

Re: Return statements and their scope - guideline

[Adam Beneschan]

On Feb 14, 8:20 am, Maciej Sobczak <no.s...@no.spam.com> wrote:
> Hi,
>
> I have found a coding guideline that allows return statements only in
> the outermost scope in the subprogram - which is supposed to avoid
> obscuring the control flow.
>
> What is outermost scope in this context?
>
> function F return Integer is
> begin
>    if Some_Condition then
>       return 0;   -- (1)
>    end if;
>    -- ...
>    declare
>      X : Integer;
>    begin
>      -- ...
>      return X;    -- (2)
>    end;
>    -- ...
>    return 7;      -- (3)
> end F;
>
> Is (1) above in the outermost scope?
> I understand that (2) is not (and is therefore discouraged) and (3)
> is
> definitely in the outermost scope, but (1) is not very obvious.

I don't think your question can be answered satisfactorily by
referring to the Ada manual.  The term "scope" is discussed in 3.1(8),
but it refers to the scope of a declaration.  The scope of the
declaration of X would be more or less the DECLARE block in which it's
declared.  But it's not really satisfactory to base a definition on
that, because it would mean that a block that declares identifiers
would be a scope, but a block that doesn't (i.e. with no DECLARE
keyword) wouldn't---and this doesn't make much sense.  As far as I can
tell, the RM never talks about a "scope" without it being the scope
"of" something---the scope of a declaration, or of a USE or WITH
clause, or maybe some other things.  So you'll have to look elsewhere.

One thing to note is that if RETURN is not allowed inside any compound
statement (such as an IF, in your example above), then there's no
point in putting it anywhere except at the end of the subprogram,
because if a RETURN statement is not performed conditionally then
everything after it is dead code.

Anyway, from the standpoint of "coding guidelines"---which really
means from the standpoint of "writing it in a way so that the next
person who reads this is less likely to have a misunderstanding"---I
would think that the main reason for not putting RETURN higher up in
the code is that if you do, and if it's a fairly sizable subprogram,
someone might look at a statement toward the end of the subprogram and
miss the fact that the statement might not always be executed because
of a RETURN statement that occurred earlier.  That's just my opinion;
I can't think of any other reason why an earlier RETURN, even a nested
one, might cause a problem.  And probably, it would cause more of a
problem for such a RETURN to be nested inside a block than otherwise.
That's how I'd think about it, and IMHO that's how you should answer
the question with respect to the real-world code you're thinking
about---an abstract example such as the one you've posted isn't going
to help answer your question.

Hope this helps.

                           -- Adam

Re: Return statements and their scope - guideline

[Adam Beneschan]

On Feb 14, 8:41 am, "Jeffrey R. Carter" <jrcar...@acm.org> wrote:
> Maciej Sobczak wrote:

> No. This is the rule in SPARK: You have to write
>
> if Some_Condition then
>     Result := 0;
> else
>     ...
>     Result := ...;
> end if;
>
> return Result;

I'm not familiar with SPARK.  What does SPARK make you do when the
function result is a string or some other unconstrained array?

                   -- Adam

Re: Return statements and their scope - guideline

[Robert A Duff]

Maciej Sobczak <no.spam@no.spam.com> writes:

> I have found a coding guideline that allows return statements only in
> the outermost scope in the subprogram - which is supposed to avoid
> obscuring the control flow.
>
> What is outermost scope in this context?

That doesn't make sense if it's using the term "scope" in the Ada sense.
Maybe it means "declarative region", which is defined in RM-8.1.
Or maybe it just means the return statement can't be nested inside
any other construct, which as Adam pointed out, means it has to be
the last statement of the function.

> function F return Integer is
> begin
>   if Some_Condition then
>      return 0;   -- (1)
>   end if;
>   -- ...
>   declare
>     X : Integer;
>   begin
>     -- ...
>     return X;    -- (2)
>   end;
>   -- ...
>   return 7;      -- (3)
> end F;
>
> Is (1) above in the outermost scope?
> I understand that (2) is not (and is therefore discouraged) and (3) is
> definitely in the outermost scope, but (1) is not very obvious.

What's the purpose of this coding convention?
In terms of readability, I see no particular difference between
(1) and (2).  Both have the problem that the programmer might
add some code at the end of the function (or procedure!),
thinking it will be executed just before returning,
but it won't.

On possibility is to put a big fat comment on returns that are buried
somewhere in the middle of the subprogram, like this:

    procedure Blah is
    begin
        ... 50 lines
        loop
            ...
            if ... then
                return; ----------------------------------------------------------------
            end if;
        end loop;
        ... 50 more lines
    end Blah;

Note that in Ada 2005 you can do things like this:

    function F return Integer is
    begin
        return Result: Integer := 123 do
            ... -- all the code of the function can go in here
            if ... then
                Result := Result + 1;
            ...
        end return;
    end F;

- Bob

Re: Return statements and their scope - guideline

[Maciej Sobczak]

Adam Beneschan wrote:

> I'm not familiar with SPARK.  What does SPARK make you do when the
> function result is a string or some other unconstrained array?

Actually SPARK handles that case very easily: unconstrained arrays 
cannot be used as return types in functions at all.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Return statements and their scope - guideline

[Maciej Sobczak]

Jeffrey R. Carter wrote:

> However, I've always felt
> 
> if Some_Condition then
>    return 0;
> end if;
> 
> is easier to read

Especially taking into account that it's not structurally different from 
"exit when" in loops, which is allowed.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/