Declaring return variables in c# methods vs returning the value directly

Question

In a debate regarding return variables, some members of the team prefer a method to return the result directly to the caller, whereas others prefer to declare a return variable that is then returned to the caller (see code examples below)

The argument for the latter is that it allows a developer that is debugging the code to find the return value of the method before it returns to the caller thereby making the code easier to understand: This is especially true where method calls are daisy-chained.

Are there any guidelines as to which is the most efficient and/or are there any other reasons why we should adopt one style over another?

Thanks

 private bool Is2(int a)
 {
 return a == 2;
 }
 private bool Is3(int a)
 {
 var result = a == 3;
 return result;
 }

• ChrisF: Both examples will compile to the identical IL. The only reason you want the second example is for debugging purposes or if you need to use result before you return it.
• tdammers: Another reason would be because you need to do something else between calculating the result and returning it.
• svick: @ChrisF, actually they don't compile to the same IL for me (there's additional stloc.0 and ldloc.0 in the second version). But I think that happens only in Debug mode. And it's not really important here anyway.
• ChrisF: @svick - OK - I should have added "in release mode" ;)
• Job: Since you can and sometimes should (for the sake of brevity) write something that looks like: a = b = c; and a == b == c, I would avoid writing something that looks like a = b == c if you can. When I first saw a line of code like that, it took me a few seconds to figure out what is going on. That code stood out. I would want to slap parenthesis around a == 3, but StyleCop does not like it - a good reason to use version number one. Something else: this is essentially a lambda, such as a => (a == 3). Why add a line of code to an already bloated trivial function?

Answer 1

Because I use Resharper with Visual Studio, Ctrl-RV (Or Ctrl-Alt-V, if you use the Resharper/IntelliJ key bindings) turns your first example into your second example. So when I want to debug, I can do that easily enough. And if I forget to put it back then I won't feel bad because Ctrl-RI will put it right back again to make it easier to read.

Seriously, waste your time arguing about more important things. Like where to put your leading braces or spaces vs tabs.

• ChaosPandion: I prefer my debates to be about invisible characters...
• pb01: Great tip, guys! Now we can continually re-factor each other's code far more quickly than we could before. It'll probably save more time than actually discussing it! :)
• Jane Doe: @pdr does that ctrl + RV work only with resharper ? or is it some sort of custom keybind? it does not work for me.
• pdr: @JaneDoe: I'm stunned to find that it is a Resharper refactoring and that VS doesn't have an equivalent. Answer corrected. Sorry about that.
• Jesse C. Slicer: @ChaosPandion U+200B for the win!

Answer 2

Personally I find the first example easier to read. You can still debug it, by setting a break point in the return statement and adding a == 2 to the watch window or by using quick watch.

But this is really a matter of personal preference. Both versions are OK.

• jk.: +1 righting harder to read code to make placing break points easier is doing things the wrong way round imho
• JustAnotherUserYouMayKnowOrNot: Watch window or intermediate window are not always solutions for this problem, as sometimes the expression requires the thread to run.
• Olivier Jacot-Descombes: @JustAnotherUserYouMayKnowOrNot: Yes. There is also the possibility to print a message into the debug window from within a breakpoint. Right click the breakpoint and select "When Hit...".
• JustAnotherUserYouMayKnowOrNot: Also the expression could have side-effects, running it again could result in problems. Better stick with the result var.
• candied_orange: Why can’t debuggers just let you see a value when you hover over return already? Seems like it’s right there on the stack.

Answer 3

When the code is as easily readable as your example, there is nothing wrong with returning the result of a logical operation such as return a == 2. However, if the return value is a more complex statement or looks something like

return a > 2? doOptionA().getResult() > makeDecision("greaterThan2") : doOptionB().getResult() == makeDecision("lessThan2");

then you'll want to use variables to store pieces of that first and simplify the return statement, for the sake of readability.

Answer 4

In a simple example such as that, either one is OK.

For more complicated examples, I prefer the second way. That is only becuase it is more readable and others will likely have to maintain the code.

• Alexander: Only if there's a better variable name than result, which is itself a completely non-descriptive and useless identifier.