Is it bad to have multiple return statements?

Question

Possible Duplicate:
Should a function have only one return statement?

Hi,

I have a code somethg like below:

    int method(string a ,int b , int c){
    if(cond1)
    return -1;

    if(cond2 || cond3)
    return 3;

    if(cond1 && cond2)
    return 0;
else
return -999;
    }

Does it perform badly when compared to having multiple if else and have single return?

EDIT:

Thank you for all your answers.

Answer 1

Performance difference will be negligible - some people may not prefer the style of this code but there will be little to no performance difference. If anything your code will be slightly faster for many cases.

Answer 2

It's perfectly OK. It also usually leads to clearer code - no deep nesting of "if"s

Answer 3

Perform badly? No. Some people think it's less readable, but that's a religious argument.

Answer 4

Does it perform badly when compared to having multiple if else and have single return?

It probably makes no difference. And if there is a difference it will probably be insignificant.

Stop wasting your time trying to micro-optimizing your code. Concentrate on trying to get your code to work, and making it easy for the next guy to read / maintain.

Answer 5

Performance difference is negligible, but multiple exit points from a function can lead to a source code difficult to mantain: if the function is non trivial it will be easy to overlook an exit point when analyzing the code searching for some problem, especially if some time passed.

Answer 6

Returning in multiple places like that is called an "early return". People use early returns sometimes to make their code run better:

e.g.

void doit( int param )
{
  // param must be +!  else no point in
  // continuing w function
  if( param < 0 )
  {
    return ;
  }

  // ... rest of code ...
  // main code returns
  return ;
}

compare with

void doit( int param )
{
  // param must be +!  else no point in
  // continuing w function
  if( param > 0 )
  {
     // .. actual code ..
  }
  else
  {
     puts( "Sorry, param must be > 0!" ) ;
  }

  // one return for all here
  return ;
}

SO, just look at the two styles and make a choice. Early returns are used in performance critical code (like intersections) because you want the function to complete as fast as possible (same code runs thousands of times per second, so every compare counts)

On the other hand "early return" code can be difficult to debug, because you might be like "Well that function doesn't even seem to run.. OH! the early return."

Answer 7

It increases the cyclomatic complexity (CI) of a function - i.e., increases the number of paths thru code more than does using the same number of if statements.

Is this bad? Yes, if your shop runs static code analysis software. And your boss sees that you bumped CI by 3. :)

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

No negative performance effect, though.

Answer 8

Putting aside the fact that your final "else" statement is redundant, there's nothing intrinsically wrong with your sample. It starts to become less than ideal from a debugging perspective when you want to trap the method's return value, because you may be left having to place breakpoints on each of the return statements. Multiple exit points aren't great, generally speaking. While your sample is manageable, it's not a stretch to imagine the need for a longer series of tests, in which case debugging becomes a chore. So assign the return value to a variable and return the variable at the end of the method.

One final point: use "switch" statements if you can (or place the most likely "success" tests towards the beginning of your list). Switch statements are quicker.

In the long term you may also find it helpful to use curly braces regardless. For example:

if (cond1) {
    return -1;
}

IMHO it's an investment as I believe it leads to fewer mistakes.

Answer 9

It can be used easily in small functions as in your example. Also, as bobobobo said, using it in "early return" is nice thing.

But It usually make big functions harder to maintain (in C at least). Imagine if you have a function with opened resources (file handler, database connection, ...) and you want to return. It will be cumbersome to close resources on each return!

Another approach we used:

int my_func(int foo)
{
   int x,y,z;
   FILE* file;
   // do some stuff
   if(x>5)
     goto my_func_end;

   // do some other stuff.

   my_func_end:
      if(file != NULL)
         fclose(file);
      return y;
}

It is better to have local-variables cleaning in one location. Also note that single return statements is advised by some coding standards, like MISRA.

There is an interesting question similar to this on here.

If you have time, take a look here and here.

Answer 10

[Code sample not quoted]

You should quit worrying about micro-optimizations and start worrying about indenting code in a way that people can read it.

Does it perform badly when compared to having multiple if else and have single return?

Any reasonable compiler (i.e., anything beyond a simple interpreter or really stupid JIT) will convert your program to a control-flow graph where it does not matter how the control flow is written in the source code. For the compiler cares, you could be using goto.

Stop worrying about the wrong things!