Storing result in a temp variable versus multiple return points

Question

Which is a better practice, generally speaking, and why? Under what circumstances would you change your mind?

function foo1(int x) {
  int result;
  if (x > 5) {
    result = 2;
  } else {
    result = 7;
  }
  return result;
}

OR

function foo2(int x) {
  if (x > 5) {
    return 2;
  } else {
    return 7;
  }
}

Answer 1

I prefer the second form where you just return immediately. The only considerations I'm aware of are as follows. Benefits:

• Shorter code
• Easier to follow
• Fewer variables (part of easier to follow, I guess)

Risks:

• May skip clean-up processing that occurs after the return

I don't worry about the risk much because that risk kind of exists anyway if you inadvertently nest the clean-up code inside a conditional block of some sort as you try to manage the various paths of execution retaining the return value until the end. I think the best bet is to keep the code simpler and easier to follow to avoid that kind of risk. I think that risk is also significantly helped by the coding structures available in modern languages such as "Using" and "Try/Finally". I try to always use those for clean-up tasks now instead of simply putting the code at the end of the block.

I do make an exception, however, when other code wants to access the pending return value as a variable anyway (to add it to a cache for example, so that the result can be returned more quickly next time).

Answer 2

I think it's better to write code that is always executed. For example the return-statement in the the first example is always executed. I keep the branching to the minimum, because no matter how hard you try, your program will sooner or later break. Then you will scratch your head trying to figure out which if-branches where executed and which not. Why not avoid that, if program breaking is so probable that it's almost a fact. :)

Answer 3

first one, because its easier to log and debug.

Answer 4

First one, because of following reasons..

1. As mentioned by "01" , easy to log and debug
2. Easy to refactor

Your code should always be in this pattern..

1. Declare variables
2. Initialize variables
3. Do Processing
4. Clean up !!!!
5. Return

In this pattern, it's easy for other people to understand how your code behaves, where to look for problems, because always "Do Processing" is the part where your business logic stays and you can certainly refactor 3rd step without affecting 4th and 5th.

If you ever get chance to see largely coded "Windows COM/DCOM Technology Source Code", they always have very standard pattern of using retval construct, and only by using standard pattern one team can achieve designing bigger and better systems, one lazy programmer can write smallest logic in terms of number of lines, but its never good for enterprise applications.

We spend lot of money on code standard tools, and we even write more code then often necessary but at enterprise level, standard practice and less complicated codes are better to maintain and grow.

By saying this, I agree that even in hurry I do not follow exact same pattern by myself many times, but I also have faced consequences, when code grows bigger, the logic becomes more complicated, the logic refactoring becomes difficult.

To write less code, we use refactoring, but not complicated logic hard to understand.

Even if you declare or do not declare retval, if you get chance to disassemble any code, you will see that compiler always declares one variable internally that is used for return anyway.

Answer 5

or

function foo2(int x) {
  if (x > 5) {
    return 2;
  }
  return 7;
}