Is leaving a procedure with a return statement a bad thing?

Question

I sometimes have colleagues frowning about using the return statement to leave a routine (before the end) because it looks like a kind of hidden goto and all gotos are evil. I neither share the thought about a goto being bad no matter how used nor can I really see why using return like this is so bad.

The question is relatively language independent. I currently program in PL/SQL and Objective-C so I give examples in this languages.

Objective-C

-(void)finishedLoading:(NSString*)result success:(BOOL)success 
{
    NSLog(@"delegate method finished loading invoked");   
    if (!success) {
        self.status.text = @"Failed to load file.";
        return; // IS THIS BAD??
    }

    self.status.text = @"File loaded.";

    // do more stuff here with result string
}

PL/SQL

PROCEDURE example(i_parameter pls_integer)
AS
BEGIN
   IF i_parameter IS NULL THEN
      RETURN; -- is this bad??
   END IF;

   -- do more stuff here

END example;

The examples are really only examples and maybe they can be criticized as they are, but I rather would like to know why the return should not be done. The only alternative that I see is to have a routine wide embracing if statement with potentially nested ifs making it hard to read but some people prefer that and I never figured out why.

what?!? no way, if there is a valid reason for the function to terminate (can't perform it's job, has located the thing searching for, etc), then it's more than valid, it's the proper thing to do IMO. — im so confused, Sep 10 '12 at 19:27
This question exists over on [Programmers.SE]: [Where did the notion of “one return only” come from?](http://programmers.stackexchange.com/q/118703/), [Best practice in setting return value (use else or?)](http://programmers.stackexchange.com/q/87965/), where it's probably, as a "whiteboard" question, a better fit. Indeed, there are at least two deleted SO instances: [Should a function have only one return statement?](http://stackoverflow.com/q/36707/), [Why should methods have a single entry and exit points?](http://stackoverflow.com/q/1701686/), suggesting it might be too subjective for SO. — jscs, Sep 10 '12 at 19:45
Although here's an extant version of it on SO: [Is it better to wrap code into an 'IF' statement, or is it better to 'short circuit' the function and return?](http://stackoverflow.com/questions/2051959/) — jscs, Sep 10 '12 at 19:46
@Josh Caswell: Thanks for pointing to answers already existing. I overlooked the one in SO and apparently this is a question already answered on Programmers which I never look into. Actually I was not much aware of its existence. — hol, Sep 10 '12 at 19:50

score 2 · Accepted Answer · answered Sep 10 '12 at 19:28

I think it's fine. In fact, I try to do all my validation at the top, either throwing or returning as necessary before the 'meat' of the method. Keeps things simpler with fewer nested-if/else's, etc. Also easier to unit-test with fewer code-paths to cover.

Scott Presnell · Answer 2 · 2012-09-10T19:47:19.593

1

Return only on exit of the procedure/function are a facet of Dijkstra's structured programming theory:

http://en.wikipedia.org/wiki/Structured_programming

(see also: http://en.wikipedia.org/wiki/Go_To_Statement_Considered_Harmful)

Theoretically, structured programming leads to easier to read code, and fewer bugs. Check it out.

edited Sep 10 '12 at 19:47

answered Sep 10 '12 at 19:33

Scott Presnell

1,490
9
23

Is leaving a procedure with a return statement a bad thing?

2 Answers2