else or return?

Question

Which one out of following two is best wrt to performance and standard practice. How does .NET internally handles these two code snippets?

Code1

If(r         


        

Answer 1

They will both compile into the same IL for Release mode (there may be a few different Nop operands in Debug..) And as such will have no performance difference. This is totally up to how you and your team feel the code is easier to read.

I used to be in the camp against early exit, but now I feel it can make code much simpler to follow.

// C#
public static void @elseif(bool isTrue)
{
    if (isTrue)
        Process1();
    else
        Process2();
}
// IL
.method public hidebysig static void  elseif(bool isTrue) cil managed
{
  // Code size       15 (0xf)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  brfalse.s  IL_0009
  IL_0003:  call       void elseif.Program::Process1()
  IL_0008:  ret
  IL_0009:  call       void elseif.Program::Process2()
  IL_000e:  ret
} // end of method Program::elseif


// C#
public static void @earlyReturn(bool isTrue)
{
    if (isTrue)
    {
        Process1();
        return;
    }
    Process2();
}
// IL
.method public hidebysig static void  earlyReturn(bool isTrue) cil managed
{
  // Code size       15 (0xf)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  brfalse.s  IL_0009
  IL_0003:  call       void elseif.Program::Process1()
  IL_0008:  ret
  IL_0009:  call       void elseif.Program::Process2()
  IL_000e:  ret
} // end of method Program::earlyReturn

Answer 2

If I had to say, I would say the better practice is the if-else rather than the "implied" else. The reason being is that if someone else modifies your code, they can easily catch it by glancing over.

I recall that there is a large debate in the programming world on whether or not you should have multiple return statements in your code. One could say that it's a source of great confusion because if you have multiple loops within the "if" statement, and have conditional returns, then it could cause some confusion.

My usual practice is to have an if-else statement and a single return statement.

For example,

type returnValue;
if(true)
{
 returnValue = item;
}
else
 returnValue = somethingElse;

return returnValue;

In my opinion the above is slightly more readable. However that isn't always the case. Sometimes it's better to have a return statement in the middle of the if statement especially if it requires a tricky return statement.

Answer 3

I think the 'single exit point' is overrated. Sticking to it too dogmatically can lead to some very complex code, which should really either have multiple exit points, or be split into smaller methods.

I would say the choice between the two depends on the semantics.

'If some condition is true then do this, otherwise do that' maps perfectly onto if-else.

if (isLoggedIn) {
    RedirectToContent();
} else {
    RedirectToLogin();
}

'If some condition then do some cleanup and bail out' maps better onto Code 2. This is called the guard pattern. This leaves the body of the code as normal, clear and uncluttered by unnecessary indentation as possible. It's commonly used to validate parameters or state (check if something is null, or something is cached, things like that).

if (user == null) {
    RedirectToLogin();
    return;
}

DisplayHelloMessage(user.Name);

It's not uncommon to see both forms used in the same project. Which to use, like I say, depends on what you're trying to convey.

Answer 4

The return will cause the code to return from whatever method the if statement is in, no further code will be executed. The statement without the return will simply drop out of the if statement.

Answer 5

If you remove the braces around the 2nd version's remaining code, that's exactly what I use. I prefer to make the early validation part of a function obvious, and then I can get down to business.

That being said, it's a matter of opinion. As long as you're consistent about it, pick one and stick with it.

edit: About the performance, the emitted IL is exactly the same. Choose one or the other for the style, there is no penalty to either.

Answer 6

Both styles are commonplace, and religious wars have been fought over them. :-)

I normally do this:

• If the test is expressing method contract semantics, e.g. checking input parameters for validity, then choose option 2.
• Otherwise, choose option 1.

However, arguably a more important rule is "which is more readable and/or maintainable for the next developer who looks at the code?".

The performance difference is negligible, as others have said.