If 'else' is about to happen anyway should it be declared or not? [duplicate]

Thi开发者_如何转开发s question already has answers here: Closed 12 years ago.

Possible Duplicate:

Should ‘else’ be kept or dropped in cases where it’s not needed?

When

a = 0

This:

var foo = function() {
  if (a != 0) return true
  return false
}

Or this:

var bar = function() {
  if (a != 0) return true
  else return false
}

---

You should do whatever makes the code clearer.

---

It gets optimized at compile time anyway, so no runtime difference.

As usual, you can argue about style. My 50 cents: the first variant (no explicit else) is nicer because it's less code doing exactly the same.

Of course, in this case, you would do

return a != 0;

... but I think the question is meant to be general.

---

I would say it's a good practice to do so, because it would make changing the code a bit easier. For instance, let's say you wanted to print out the result. You could either change it like this:

if (a != 0) {
    print "returning true"
    return true
}
print "returning false"
return false

Which means adding a print twice, or else:

if (a != 0) {
    retval = true
} else {
    retval = false
}

print "returning ", retval
return retval

which means adding one print, but this won't work without the else.

Of course, this is a contrived example, but it shows how you should try to make your code as maintainable as possible.

---

As the compiler will probably reduce it to the same compiled code anyway, do what you believe to be more "beautiful".

Note that code elegance is subjective, so dogmatically clinging to one format or another is unnecessary.

---

if(statement)
       result = true
else
       result = false

return result

---

Both would work the same in most languages, but I'd think using else would be best to make it more obvious that when none of the if/else if statements above are true, then do this, even though this obviously isn't necessary.
But, however, if you have a lot of code below the if statement, then you shouldn't do this, since it would only become a huge mess with a lot of unnecessary else statements.

---

If the language requires braces for if/else statements, I personally like to remove the else statement and the accompanying braces. The intention of the code will be just as clear, but the code will be less indented, which (usually) improves readability.

As others mentioned, the compiler will optimize the else statement. But if you're dealing with an interpreted language, the else statement has to be interpreted. In that case removing it will result in a minor (very minor) performance increase.

---

Of course "else" should be declared explicitly.

There are several reasons why 'else' should be declared explicitly :

1. Readability
   I won't sacrifice readability for some "cool" programming style. But, i will understand if you're facing bandwith-oriented problem like minifying javascript.
2. Conceptual. Your first code doesn't tell the human reader "what will you do if the 'if guard' returns false". Instead, your code tells the reader that "default value is false, true only happens when bla-bla-bla". Or in another word, your code tells the reader that "I assume the value is false, it's true only when bla-bla-bla".

On the conceptual reason above, it - of course - depends on your function specification. For some function it makes sense to use such code. For example "Function assumes the visitor is not registered, he is only registered only if bla-bla-bla".

But for another problem like "If a number is divisible by two then it is even otherwise odd", you should write it explicitly so that a reader (perhaps not a programmer) will not be confused when reading your code. Since the reader (maybe a mathematician) only knows such invariant and he/she only knows a little about programming language.

---

I would tend to not use the else if it is superfluous, any developer should understand what is going to happen:

public void DoSomethingConditionally(Foo foo)
{
    if (Bar)
    {
        foo.DoX();
        return;
    }
    foo.DoY();
}

I disagree with people who want only one return point per function, your functions should be small and a few return points enhance rather than hinder readability.

---

Just stick in an else and move on to something more exciting!

---

IMO - If your intention is to return true when some condition is met, (e.g. something is found), and then maybe process the data other way, and at last, when nothing is found, return false, the option without else is clearer.

If your return value depends only on the condition in if, the if-else variant looks better.

---

It doesn't matter. The compiler will turn out the same code either way. Check to see what convention existing code follows, and then just do the same.

Personally I don't put the "else" because it's obvious. I find that the extra "else" looks cluttered.

---

I personally like the Syntax:

/*Function header comments*/
Function(...)
{ 
  /*English what the if is trying to achieve*/
  If(...)
  {
    ...
    Return True; /*What this tells me*/
  }
  Else
  {
    ...
    Return False: /*What this tells me*/
  }
}

Simply because I find myself in the situation if I simply do

If(...)
Return True;
Else
Return False;

or

If(...)
Return True;

Return False;

or

(...)?Return True:Return False;

That it's not as clear,even though with the right comment the one liner is cool, and if I'm doing a comparison anyways there is a good chance that down the road I may think of something that needs to happen in that area anyways, I mean I'm doing an if for more than grins. Also if I find a special case that needs an Else If its just a matter of adding in the Else If portions.

---

function DoSomethingConditionally(foo)
{
    if (Bar)
    {
        foo.DoX();
        return;
    }
    else
    {
        foo.DoY();
    }
}

I like this style, just in case I need to add something later.

---

My decision whether or not to use the "else" depends upon my semantic interpretation of the "if" and, in some cases, the return value. In cases where I feel the "if" is deciding between two courses of action or two return values, I will use the "else". In cases where I feel it's deciding between acting normally and "aborting early", I'll skip the else. In cases where the return value answers the question, "Did something fail", I'll generally regard an error return as an early abort, even if the only remaining thing to do would be return success, and thus skip the "else". If, however, the return value asks, "Is something xxx", then I'll far more often include the "else".

---

The example is overly simplistic. Most of the answers are advocating a coding short-cut which dodges the true question about logic branches. The compiler may optimize out the else branch so that it is logically equivalent to not using the else branch, but why make the compiler work more? If this is a scripting language that gets compile often, there's no reason to add the extra "else".

Also, source code analyzers will not optimize this out. The extra "else" will count as another logic branch. This might make your functions more "complex" than they are. See "CRAP Index", "Cyclomatic Complexity", and other software metrics.

http://en.wikipedia.org/wiki/Cyclomatic_complexity

If both of the following examples get compiler optimized to the same byte-code, pick whichever style suits you and stick to it. Personally, I feel the first example is more maintainable.

public void DoSomethingConditionally(Foo foo)
{
    if (Bar)
    {
        foo.DoX();
        return;
    }
    if (Baz)
    {
        foo.DoZ();
        return;
    }

    foo.DoY();
}



public void DoSomethingConditionally(Foo foo)
{
    if (Bar)
    {
        foo.DoX();
    }
    elseif (Baz)
    {
        foo.DoZ();
    }
    else 
    {
        foo.DoY();
    }
    return;
}

---

The LLVM Coding Standards and the Mozilla Coding Style both state that else should not be used after a return.

---

In this case just return the expression result directly.

return (a != 0)

But in general I try to avoid having returns from the middle of a function. Have one return per function.