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?


    private bool Is2(int a)
        return a == 2;

    private bool Is3(int a)
        var result = a == 3;
        return result;
  • 12
    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.
    – ChrisF
    Commented Mar 27, 2012 at 12:33
  • 1
    Another reason would be because you need to do something else between calculating the result and returning it.
    – tdammers
    Commented Mar 27, 2012 at 12:35
  • 1
    @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.
    – svick
    Commented Mar 27, 2012 at 12:56
  • @svick - OK - I should have added "in release mode" ;)
    – ChrisF
    Commented Mar 27, 2012 at 12:57
  • 3
    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?
    – Job
    Commented Mar 27, 2012 at 13:33

4 Answers 4


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.

  • 5
    I prefer my debates to be about invisible characters... Commented Mar 27, 2012 at 13:23
  • 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! :)
    – pb01
    Commented Mar 28, 2012 at 8:06
  • @pdr does that ctrl + RV work only with resharper ? or is it some sort of custom keybind? it does not work for me.
    – Jane Doe
    Commented Mar 17, 2013 at 12:23
  • @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.
    – pdr
    Commented Mar 17, 2013 at 13:47
  • @ChaosPandion U+200B for the win! Commented Aug 21, 2019 at 14:07

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.

  • 9
    +1 righting harder to read code to make placing break points easier is doing things the wrong way round imho
    – jk.
    Commented Mar 27, 2012 at 13:05
  • Watch window or intermediate window are not always solutions for this problem, as sometimes the expression requires the thread to run. Commented Mar 17, 2013 at 15:33
  • @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...". Commented Mar 17, 2013 at 16:26
  • Also the expression could have side-effects, running it again could result in problems. Better stick with the result var. Commented Mar 18, 2013 at 6:53
  • 1
    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. Commented Jan 22, 2020 at 2:04

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.


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.

  • Only if there's a better variable name than result, which is itself a completely non-descriptive and useless identifier.
    – Alexander
    Commented Aug 22, 2019 at 17:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.