|
The rule of thumb I usually use is to place the most frequently encountered condition first. A professor in college taught me this - it can actually make the program more efficient since that reduces the number of conditions that need to be checked. Granted, if the statement only has a single IF with an unconditioned ELSE, this doesn't make any difference, but if you are using an ELSEIF or CASE construct, it can make a huge difference.
Then again, I went to college way back when saving a few CPU cycles actually mattered... 
|
|
|
|
|
Pretty much agree with that thinking for CASE constructs of putting the most likely. Although I do break it fairly often too. For instance, I usually assume that someone else will get their hands dirty in my code sometime on the future, so I may use a more 'obvious' ordering to the conditions for the benefit of any poor sucker that comes behind.
However, when it comes to XSLT choose blocks I've often found it necessary to put the weird edge cases first and then proceed to the more commonly expected ones later. In other words filter out the strange stuff that requires special handling before you get to what you're really after. Unfortunately this is more CPU intensive, but then again that's XSLT. 
I just love Koalas - they go great with Bacon.
|
|
|
|
|
In cases where you cannot tell which condition will be taken more often I put the smaller clause first in the hopes that a false prediction won't necessarily cause as much cache pollution.
|
|
|
|
|
That is what I do. I wonder if this is what most of 69% "depends on the situation" category do? I see the need to re do this poll..
John
|
|
|
|
|
Ed Leighton-Dick wrote: Then again, I went to college way back when saving a few CPU cycles actually mattered...
They still matter IMO. They're so cute when all fluffy and running about, we must save them!
|
|
|
|
|
No ifs and buts in my code 
|
|
|
|
|
this.FullOfFoo = this.Nationality == "Serbian";
//
|
|
|
|
|
 haug,serbian brother !
|
|
|
|
|
Srbija do CodeProject-a... :P
|
|
|
|
|
Stupid poll.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Interestingly, the votes go to "depends on the situation", rather than random.
This means that most of us do have a strong preference, given a specific condition to test.
Or that most of us didn't read beyond the 3rd option.
|
|
|
|
|
peterchen wrote: Or that most of us didn't read beyond the 3rd option
I was also wondering that!
|
|
|
|
|
I agree on 2ed one that most of them didn't read after 3ed option 
Whatever you do will be insignificant, but it is very important that you do it
|
|
|
|
|
The question is not really pointless, since there are people who have strong opinions about it (usually "always test for positive conditions"). Since I never had explained or understood the "why", I won't judge
My prime directives influencing the style of conditions are simplified reading (i.e. reading the code aloud is close to the condition I want to express), reduced nesting and testing cheaper conditions first. So it's e.g.
<br />
if (itemCount == 0) <br />
return false;<br />
<br />
if (!file.Exists()) <br />
return false;<br />
<br />
...<br />
<br />
return true;<br />
|
|
|
|
|
 You will burn on a stake for that!
While we were at strong opinions...
Personally, I have no problem with multiple returns. But an amazing number of styleguides strongly forbid it - contrary to intuition and code readability, as I think.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
It made sense in C / procedural style, where "one exit point" made sense for avoiding ressource management errors.
However in any modern language we have exceptions thwarting the effort anyway, and deterministic destructors/finalizers to deal with the problem.
|
|
|
|
|
I like this style as well. Not only for the readability but also because it better reflects what the code is doing - it's making several tests whether it can safely go ahead with whatever action it's going to perform or if something's wrong and it should fail.
I hate it when if ... else ... if ... else ...... is used instead because it can confuse you by suggesting branching where there is none.
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
Agreed.
---- You're right.
These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets .
|
|
|
|
|
It depends on the relative lengths of the then and else clauses. If both are short then I'm more likely to put the true clause first. If one if short (often because its an error case) and the other is long then the shorter one comes first. This makes it easier to determine which if statement a code block belongs to.
For instance
if(statement is false)
return ERROR_CODE;
else
{
}
in preference to
if(statement is true)
{
}
else
{
return ERROR_CODE;
}
Of course, if both are long (or even if just one of them is long) I'd refactor the long code into functions, i.e.
if(statement is false)
DoLongComplicatedStuff();
else
DoOtherLongComplicatedStuff();
Graham
Librarians rule, Ook!
|
|
|
|
|
For me it depends on the frequency of each of the outcomes. Which ever is likely to happen most often is the "if", and the less frequently encountered condition is the "else".
If they are equally likely, or nearly so, I tend to use the true case as the if, 'cause I don't usually like reading negative logic.
/bs
|
|
|
|
|
Yours is my preferred method. Though sometimes there are cases that either the false or true statement just makes it easier to understand what is happening. In some cases where I have if..then..else but no case statements I'll handle the only definitive answer first and handle the opposite and "maybe" answers elsewhere.
|
|
|
|
|
Graham Shanks wrote:
For instance
if(statement is false)
return ERROR_CODE;
else
{
}
in preference to
if(statement is true)
{
}
else
{
return ERROR_CODE;
}
This should be rewritten as follows for clarity and reduced code size.
if(statement is false)
{
return ERROR_CODE;
}
There is NO ELSE.
Gary
|
|
|
|
|
And THAT makes it even easier to read! Good catch!
Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.
|
|
|
|
|
if(areUsingTDD)
thisQuestionDoesntReallyMakeSense
|
|
|
|
|
How does TDD fit in here?
You don't use coditions in TDD?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
