Is "if/else" better than "if/return"? If you want to easily refactor, then yes.

(archived from my old blog from my pre-MS days)

Look at the following piece of code:

private void DbMove(CopyInfo info)
{
string targetDb = GetTargetDB(info);
if (targetDb.Equals(string.Empty))
return;

    PrepDbsForCopy(info.SourceDb, targetDb);

    GetAllData(info);
if (IsNoSourceData())
return;

    int upperBound = GetUpperBound();
int rangeCount = GetRange();

    if (CopyNotCurrentlyPossible(_isDisconnected, _isHomogenous))
return;

    DoAsyncDbCopy(info, upperBound, rangeCount, _isDisconnected, _isHomogenous);
}

Now this is a standard piece of code with several "short-circuit" returns in the code.  Short-circuiting is good, but usually only if it appears as the first instruction in the method, and only once.  Otherwise, refactoring the code (as above) is a bear.  Select a section of text to pull out (extract method), and if it contains a "return" or break, or anything like that, then you'll most likely get a complaint from your refactoring tool.  ReSharper 4 complains "Extracted block has exits to different points Proceed with refactoring?(sic)".  Besides the pain from lack of proper punctuation (just a typo, I'm sure), the pain of not being able to refactor when you want to is even worse.

However, you can refactor if you do some manual refactoring (and this is still easier than manually extracting the method).  Instead of:

    string targetDb = GetTargetDB(info);
if (targetDb.Equals(string.Empty))
return;

    ...

Try the following:

    string targetDb = GetTargetDB(info);
if (targetDb.Equals(string.Empty))
return;
    else
    {
        ...
}

Then you can start using your refactoring tools like "Invert If"

    string targetDb = GetTargetDB(info);
if (!targetDb.Equals(string.Empty))
    {
        ...
}
else
return;

And "voila," your else can be tossed as cruft.  Do so with the other "if"s and yes, you have more indented blocks of code, but indented blocks of code can be easily refactored with "Extract Method."