Code style question - disparate then/else sizes
-
If you have an if/else with one branch significantly larger than the other, how do you normally order them when keeping the conditional understandable doesn't drive the decision?
if (x < 10)
{
//short code block
}
else
{
//long code block
}of like this:
if (10 <= x)
{
//long code block
}
else
{
//short code block
}Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull
don't know it this will help but I always try to keep the "normal" conditional path in the "if" part instead of the "else" part of the condition, so if it means testing on "!=" instead of "==" I will do it.
Maximilien Lincourt Your Head A Splode - Strong Bad
-
Generally it's always a bad idea to compare a literal to a variable ("10<=X") because it tends to throw people who look at it too fast. That being said, most people tend to believe that you should set the conditional to be the most likely case to run - in your example case, if you think that x will be a value less than 10 more often than it will be 10 or more.
Please don't bother me... I'm hacking right now. Don't look at me like that - doesn't anybody remember what "hacking" really means? :sigh:
Robert Royall wrote:
Generally it's always a bad idea to compare a literal to a variable ("10<=X") because it tends to throw people who look at it too fast.
On the other hand, it doesn't invite problems like these:
if(x = 0) { ... }
-- Kein Mitleid Für Die Mehrheit
-
If you have an if/else with one branch significantly larger than the other, how do you normally order them when keeping the conditional understandable doesn't drive the decision?
if (x < 10)
{
//short code block
}
else
{
//long code block
}of like this:
if (10 <= x)
{
//long code block
}
else
{
//short code block
}Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull
Don't care, although if I had to choose I'd put the short one first.
Kind regards, Pawel Krakowiak Miraculum Software[^]
-
If you have an if/else with one branch significantly larger than the other, how do you normally order them when keeping the conditional understandable doesn't drive the decision?
if (x < 10)
{
//short code block
}
else
{
//long code block
}of like this:
if (10 <= x)
{
//long code block
}
else
{
//short code block
}Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull
I agree with the others saying make the first part the primary. I treat if/elses as primary and exception regardless of size. There are times when handling the exceptional case requires more work and is sometimes longer and other times where it is not, but in general the majority of your cases should go through the if, not the else. If the latter is true, you may have a design issue you were not aware of, in which case it is good to know through optimization steps that your assumptions were wrong and decide how to correct them. Knowing that the primary path is in the first block means you can easily find when you made an improper assumption, if code directs more often to the else, it is time to find out why, not just flip the if around. When you understand why, and the fix is flip the code around, that is fine, but it could be that there is an issue in the input of x that you didn't know about, and fixing it causes the code to direct through the proper section more often. Keeping the code this uniform as primary and exception leads to easier times optimizing if you keep up with it, that is.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
If you have an if/else with one branch significantly larger than the other, how do you normally order them when keeping the conditional understandable doesn't drive the decision?
if (x < 10)
{
//short code block
}
else
{
//long code block
}of like this:
if (10 <= x)
{
//long code block
}
else
{
//short code block
}Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull
As others have said, I would tend to put the positive, normal case in the 'if' arm and the exception case in the 'else' part. If that means that the 'else' part confuses the flow of the normal logic, pull out the 'else' part into a separate function. This can have the effect of speeding up the normal flow because more of the normal flow fits into the processor's cache! Microsoft actually use this approach in Windows - they seem to have a tool which will pull out error-handling code onto a different page from the regular code path, so that the error path isn't even paged in until needed.
DoEvents: Generating unexpected recursion since 1991
-
If you have an if/else with one branch significantly larger than the other, how do you normally order them when keeping the conditional understandable doesn't drive the decision?
if (x < 10)
{
//short code block
}
else
{
//long code block
}of like this:
if (10 <= x)
{
//long code block
}
else
{
//short code block
}Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull
As others have said, I would prefer to use the primary result with the 'if', and then other conditions in reducing order of appearance (assuming there may be an 'elseif' or two...) On a similar note, if using a 'case' statement, I prefer my conditions in alphabetical/numerical order. Tim
-
If you have an if/else with one branch significantly larger than the other, how do you normally order them when keeping the conditional understandable doesn't drive the decision?
if (x < 10)
{
//short code block
}
else
{
//long code block
}of like this:
if (10 <= x)
{
//long code block
}
else
{
//short code block
}Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull
-
Generally it's always a bad idea to compare a literal to a variable ("10<=X") because it tends to throw people who look at it too fast. That being said, most people tend to believe that you should set the conditional to be the most likely case to run - in your example case, if you think that x will be a value less than 10 more often than it will be 10 or more.
Please don't bother me... I'm hacking right now. Don't look at me like that - doesn't anybody remember what "hacking" really means? :sigh:
I always write my inequalities with the low on the left. After a decade and a half of being programmed that way by math classes in school any other ordering of an interval throws me.
Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull
-
don't know it this will help but I always try to keep the "normal" conditional path in the "if" part instead of the "else" part of the condition, so if it means testing on "!=" instead of "==" I will do it.
Maximilien Lincourt Your Head A Splode - Strong Bad
That's not an unreasonable standard if you know which branch is preferred. In this case I'm reverse engineering requirements out of existing code. I don't know which case is preferential, and am 95% sure based on history that when the first version was written there wasn't an else clause at all, so I can't get any insight that way. At present I'm not looking to actually refactor it. Even if I was redoing the VBA instead of converting similar C# code into managed COM objects to use only a single codebase I've got much higher priorities to cleanup than reordering if/else pairs.
Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull
-
Never thought about it to be honest and don't try to do it any particular way. I guess if I had to choose it would make far more sense to put the short code block first for readability so it doesn't get lost in the long code block. I always slap a #region directive around a long code block though so maybe that's why I never noticed before.
When everyone is a hero no one is a hero.
John C wrote:
I always slap a #region directive around a long code block though so maybe that's why I never noticed before.
Not a big fan of refactoring, eh John? ;)
-
If you have an if/else with one branch significantly larger than the other, how do you normally order them when keeping the conditional understandable doesn't drive the decision?
if (x < 10)
{
//short code block
}
else
{
//long code block
}of like this:
if (10 <= x)
{
//long code block
}
else
{
//short code block
}Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull
I would myself put the short code block before, but it depend on the condition. I try to avoid negative (if (!true))condition in the if clause. :doh:
-
Robert Royall wrote:
Generally it's always a bad idea to compare a literal to a variable ("10<=X") because it tends to throw people who look at it too fast.
On the other hand, it doesn't invite problems like these:
if(x = 0) { ... }
-- Kein Mitleid Für Die Mehrheit
Compilers have been capable of issuing diagnostic messages for that sort of thing for over ten years now. I think the loss of readability of
if (0 == x) { /* ... */ }
far outweighs any benefit in detecting the incorrect operator.
Software Zen:
delete this; -
John C wrote:
I always slap a #region directive around a long code block though so maybe that's why I never noticed before.
Not a big fan of refactoring, eh John? ;)
I saw your wink, but I'm not sure what refactoring has to do with putting regions around code blocks for readability. I'm not a big fan of writing sloppy code in the first place and poor designs that will clearly need refactoring later but that being said I've been spending nearly the entire last week refactoring my setup and deployment system for a very large app.
When everyone is a hero no one is a hero.
-
If you have an if/else with one branch significantly larger than the other, how do you normally order them when keeping the conditional understandable doesn't drive the decision?
if (x < 10)
{
//short code block
}
else
{
//long code block
}of like this:
if (10 <= x)
{
//long code block
}
else
{
//short code block
}Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull
As much as possible I try to write each function as a linear segment of code. About 75% or higher of my if statements are checking for conditions that result in exiting the method early rather then requiring an else. I find this much easier to follow as most of the code that actually causes side effects is close to the end of the method, and the rest is filters that lets execution down to the code that "does stuff". When I do write else blocks I usually put the shorter block first.
This blanket smells like ham
-
Generally it's always a bad idea to compare a literal to a variable ("10<=X") because it tends to throw people who look at it too fast. That being said, most people tend to believe that you should set the conditional to be the most likely case to run - in your example case, if you think that x will be a value less than 10 more often than it will be 10 or more.
Please don't bother me... I'm hacking right now. Don't look at me like that - doesn't anybody remember what "hacking" really means? :sigh:
Robert Royall wrote:
Generally it's always a bad idea to compare a literal to a variable
Really? I've found it to be a good practice for decades now. I usually only use it in straight equality comparisons though as other types are a bit harder to read.
When everyone is a hero no one is a hero.
-
As much as possible I try to write each function as a linear segment of code. About 75% or higher of my if statements are checking for conditions that result in exiting the method early rather then requiring an else. I find this much easier to follow as most of the code that actually causes side effects is close to the end of the method, and the rest is filters that lets execution down to the code that "does stuff". When I do write else blocks I usually put the shorter block first.
This blanket smells like ham
Andy Brummer wrote:
About 75% or higher of my if statements are checking for conditions that result in exiting the method early rather then requiring an else
Yes! That's actually what I do in practice more often than not. I call it "short circuiting" and at every opportunity I look for a short circuit that can go early in the method. All those years of coding on slow hardware I guess just make it a habit.
When everyone is a hero no one is a hero.
-
Andy Brummer wrote:
About 75% or higher of my if statements are checking for conditions that result in exiting the method early rather then requiring an else
Yes! That's actually what I do in practice more often than not. I call it "short circuiting" and at every opportunity I look for a short circuit that can go early in the method. All those years of coding on slow hardware I guess just make it a habit.
When everyone is a hero no one is a hero.
John C wrote:
Yes! That's actually what I do in practice more often than not. I call it "short circuiting" and at every opportunity I look for a short circuit that can go early in the method. All those years of coding on slow hardware I guess just make it a habit.
It is still a matter of putting most execution up front. The knowledge that you have to weed out a majority to find a solution is common. For instance simulating a sensor, Range cuts out the largest land area, if your sensor's range is 2km then you just cut out 99.999% of of the earth or something like that in one conditional. Now you can narrow it down based on other parameters, each step bringing you close to the desired item and action. Even those with big hardware should pay attention to such things. If you have 1000 items to find one of interest, and you have a zillion other actions to accomplish as well, the faster you weed out the failures the better so that you can do other things. There is always more computation you can add on a fast machine, better to use that in the fancy additions than the humdrum activities, so the faster your code the better. :-D
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
If you have an if/else with one branch significantly larger than the other, how do you normally order them when keeping the conditional understandable doesn't drive the decision?
if (x < 10)
{
//short code block
}
else
{
//long code block
}of like this:
if (10 <= x)
{
//long code block
}
else
{
//short code block
}Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull
There's an error in your code :-) I'd probably refactor the long block to a method, if it was really long ( and then make it first as it would be the shortest ), or if it wasn't *that* long, I'd put the short block first.
Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
-
If the language in C#, then wouldn't
#region CodeSnippet #endregionalso lend some helping hands?Vasudevan Deepak Kumar Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson -
Robert Royall wrote:
Generally it's always a bad idea to compare a literal to a variable
Really? I've found it to be a good practice for decades now. I usually only use it in straight equality comparisons though as other types are a bit harder to read.
When everyone is a hero no one is a hero.
Thanks for taking my quote out of context. ;P
Robert Royall wrote:
Generally it's always a bad idea to compare a literal to a variable because it tends to throw people who look at it too fast.
How many maintenance programmers scanning through an assignment like (10 <= x) are going to see (x <= 10) instead? Granted, if you only use it for equality it's obviously not a problem no matter how you read it.
Please don't bother me... I'm hacking right now. Don't look at me like that - doesn't anybody remember what "hacking" really means? :sigh: