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;
  • 11
    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 Mar 27 '12 at 12:33
  • 1
    Another reason would be because you need to do something else between calculating the result and returning it. – tdammers Mar 27 '12 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 Mar 27 '12 at 12:56
  • @svick - OK - I should have added "in release mode" ;) – ChrisF Mar 27 '12 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 Mar 27 '12 at 13:33

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... – ChaosPandion Mar 27 '12 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 Mar 28 '12 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 Mar 17 '13 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 Mar 17 '13 at 13:47
  • @ChaosPandion U+200B for the win! – Jesse C. Slicer Aug 21 '19 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.

  • 8
    +1 righting harder to read code to make placing break points easier is doing things the wrong way round imho – jk. Mar 27 '12 at 13:05
  • Watch window or intermediate window are not always solutions for this problem, as sometimes the expression requires the thread to run. – JustAnotherUserYouMayKnowOrNot Mar 17 '13 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...". – Olivier Jacot-Descombes Mar 17 '13 at 16:26
  • Also the expression could have side-effects, running it again could result in problems. Better stick with the result var. – JustAnotherUserYouMayKnowOrNot Mar 18 '13 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. – candied_orange Jan 22 '20 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 Aug 22 '19 at 17:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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