views:

166

answers:

7

I have a method that checks certain things and returns a Boolean based on those checks. It involves a single branching If section that checks about 5 conditions in sequence. If any of those conditions return true, then the method will return true;. If none of the conditions return true, then the method will return false;. Since the code after the If section will only run if none of the conditions are true, then that code is logically identical to including an actual Else statement.

So is it a better idea to actually write in the Else statement for this kind of situation?

EDIT

It turns out that I needed information on which condition actually tripped the "true" for some of these, so I changed the method to return an int, with -1 representing the "false" situation. The logic still remains, if none of the conditions are true, it'll return -1. So, I no longer have the condensable option of return (cond1 || cond2 || cond3 || cond4 || cond5);, but I thank everyone for that suggestion too, since I had indeed not thought about it (primarily because cond3 is a very complex condition involving checking for intersection in the midpoints of two pairs of DateTime objects, so it would look ugly). While the nature of the method has changed, the nature of this question has not and all answers are still basically applicable...

The code is currently, to paraphrase it and cut out all the extraneous code that defines cond1 thru cond5...

if (cond1) { return 1; }
else if (cond2) { return 2; }
else if (cond3) { return 3; }
else if (cond4) { return 4; }
else if (cond5) { return 5; }
+3  A: 

Whatever expresses your intention best and/or is most readable.

All the following options are perfectly valid:

if (condition1)
    return true;
if (condition2)
    return true;
if (condition3)
    return true;
return false;

or

if (condition1)
    return true;
else if (condition2)
    return true;
else if (condition3)
    return true;
else
    return false;

or

return condition1
    || condition2
    || condition3;

I tend to use the first two options if the conditions are non-trivial or if there are multiple statements in the if branch. The last option can give much more concise code if the conditions aren't to complex.

dtb
+5  A: 

It's really a matter of style and what you (and those you work with) find to be clearer. In general, I personally find the structure:

if( a )
   someResult = doSomething();
else if( b )
   someResult = doSomethingElse();
else
   someResult = doSomethingAnyways();

return someResult;

clearer than:

if( a )
    return doSomething();
if( b )
    return doSomethingElse();
return doSomethingAnyways();
LBushkin
I agree it's a matter of style, and personally I prefer the opposite of what you prefer! The latter option above is cleaner and has less code, and I prefer it for that reason.
Cheeso
The first option is easier to refactor into a new method, that's why it's better.
Hightechrider
I tend to prefer a single exit point from a method when it's possible without complicating the logic of the code. I find that methods with a single exit point are easier to understand, refactor, and maintain. There's also a convenient place to put a breakpoint where you can still tweak the return value before allowing execution flow to resume.
LBushkin
+1  A: 

Without actually seeing your code it's difficult to say, but given that you've got a number of conditions that produce a true it might be clearer to just have the code fall through and have a final return false; at the end:

public bool MyComplicatedTest()
{
    if (complicated_condition1)
    {
        return true;
    }

    if (complicated_condition2)
    {
        return true;
    }
    ....

    return false;
}
ChrisF
+1  A: 

Sounds like you're asking if this:

if ((condition1) ||
   (condition2) ||
   (condition3) ||
   (condition4) ||
   (condition5) )
{
   return true;
}
else
{  return false;
}

can be turned into this:

if ((condition1) ||
   (condition2) ||
   (condition3) ||
   (condition4) ||
   (condition5) )
{
  return true;
}
return false;

Yes.

Consider this as well:

return ((condition1) ||
   (condition2) ||
   (condition3) ||
   (condition4) ||
   (condition5) )
p.campbell
+1  A: 

This is purely a matter of style and taste.

My personal preference is to include the else only if there is an either-or situation.

if (SomeCondition())
    return "Boxers";
else
    return "Briefs";

If there are several returns in a method, then I will omit the final else.

if (!OvenOn())
    return false;
if (timeRemaining <= 0d)
    return false;
if (DoorOpen())
    return false;
return true;

This scheme seems to give the most clarity, in my opinion.

Jeffrey L Whitledge
+1  A: 

I tend to prefer something like this to returning hard values.

static bool SomeFunc(string arg)
{
    bool result = false;

    if (arg.Length < 10)
    {
        result = true;
    }
    else if (arg.StartsWith("foo"))
    {
        result = true;
    }

    if (!result && arg.EndsWith("foo"))
    {
        result = true;
    }

    return result;
}
Felan
IMO this is a perfect candidate for shortening it to `return (arg.Length < 10) || arg.StartsWith("foo") || arg.EndsWith("foo")`
dtb
Sure but those aren't what I would call realistic conditionals. The intent is that I think its better set a default to your return result and process against that than sprinkle return statements everywhere. I don't think its wrong to have more than one return statement just think it hurts clarity to have a ton of return statements and it also makes it harder to debug.
Felan
+1  A: 

Personally, I generally prefer to use the ELSE because I think it makes the intent clearer. If you write

if (sensorScan()==ENEMY)
  return FIRE_PHASERS;
else
  return SEND_GREETING;

it is clear to the reader that you are dealing with two branches coming out of one condition. Sure, in a trivial case like this where each branch is just one line, that might be obvious anyway. But in real life you often have a block of many lines of code inside the IF and many conditions, so it might well not be immediately obvious to a reader that every block ends with a return and the last block is therefore only executed when all previous conditions are false.

One exception I make to this practice is when the code is deeply nested. When it starts crawling too far across the page, I often find it more readable to remove the ELSEs.

Another excpetion is when one condition is an odd case and the other condition is the main-line. Yes, this is completely subjective, but in such cases I prefer to put the main-line outside the ELSE when possible.

Jay