Code style question - disparate then/else sizes
-
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:
-
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.
I like #region as well, but it drives my co-worker batty. *sigh* :sigh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
-
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
if statements are evil. If they can't be handled by inheritence, or it doesn't make sense to express the logic in a state or decision graph, then (no pun intended on this sentence):
if ([some expression]
{
DoThis();
}
else
{
DoThat();
}rather than embedding a bunch of probably re-usable code in the statement itself. Besides, it makes it a lot more readable as to what you're doing. Of course, yes, there are exceptions. Marc
-
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
A little off topic: When you do that, do you just exit the method at that point? It was always drilled into my head that all methods (in the old days we called them "functions") should only have one exit point, but if I try to follow that mandate in situations like you described above, I end up jumping through hoops to make that happen, so I often tend to be "guilty" of simply putting a "return" inside my if at the point I want it to exit. Hopefully that does not brand me as a horrible coder. I had one coworker who thought it was neat to get around that (in C/C++) by coding something like:
do { if (somecondition) break; if (someothercondition) break; //etc. } while (false)(It will execute the above loop only one time as coded.) I always thought that was simply horrible!WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
-
Andy Brummer wrote:
About 75% or higher of my if statements are checking for conditions that result in exiting the method early
A little off topic: When you do that, do you just exit the method at that point? It was always drilled into my head that all methods (in the old days we called them "functions") should only have one exit point, but if I try to follow that mandate in situations like you described above, I end up jumping through hoops to make that happen, so I often tend to be "guilty" of simply putting a "return" inside my if at the point I want it to exit. Hopefully that does not brand me as a horrible coder. I had one coworker who thought it was neat to get around that (in C/C++) by coding something like:
do { if (somecondition) break; if (someothercondition) break; //etc. } while (false)(It will execute the above loop only one time as coded.) I always thought that was simply horrible!WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
Tom Delany wrote:
A little off topic: When you do that, do you just exit the method at that point? It was always drilled into my head that all methods (in the old days we called them "functions") should only have one exit point, but if I try to follow that mandate in situations like you described above, I end up jumping through hoops to make that happen, so I often tend to be "guilty" of simply putting a "return" inside my if at the point I want it to exit. Hopefully that does not brand me as a horrible coder.
I do the same with a caveat, if I have more than 2 or 3 conditions (or the single condition is really complex), I move all the validation into a seperate
boolfunction, splatter a mess ofreturn false's thoughout, and then only have 1 validation exit at the very beginning of the function.Tom Delany wrote:
(It will execute the above loop only one time as coded.) I always thought that was simply horrible!
:confused: X| :omg: :wtf:
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
-
if statements are evil. If they can't be handled by inheritence, or it doesn't make sense to express the logic in a state or decision graph, then (no pun intended on this sentence):
if ([some expression]
{
DoThis();
}
else
{
DoThat();
}rather than embedding a bunch of probably re-usable code in the statement itself. Besides, it makes it a lot more readable as to what you're doing. Of course, yes, there are exceptions. Marc
Marc Clifton wrote:
if statements are evil.
First they make goto's evil, and now if's? I think it's time for me to retire. :sigh:
-
Andy Brummer wrote:
About 75% or higher of my if statements are checking for conditions that result in exiting the method early
A little off topic: When you do that, do you just exit the method at that point? It was always drilled into my head that all methods (in the old days we called them "functions") should only have one exit point, but if I try to follow that mandate in situations like you described above, I end up jumping through hoops to make that happen, so I often tend to be "guilty" of simply putting a "return" inside my if at the point I want it to exit. Hopefully that does not brand me as a horrible coder. I had one coworker who thought it was neat to get around that (in C/C++) by coding something like:
do { if (somecondition) break; if (someothercondition) break; //etc. } while (false)(It will execute the above loop only one time as coded.) I always thought that was simply horrible!WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
I always thought that came from long overly complicated methods that had a lot of state to "unroll" when you exited from the method. Also, if you are using raw new/delete calls, then this is almost impossible to do. In C++ it really requires using some kind of smart pointer to support. If I'm not able to cleanly throw an exception or exit with a simple return then I simplify the method until I can. If there is too much going on, I'll even create a transactional object that I can just throw away. I agree with you about that do while crap. Ugh.
This blanket smells like ham
-
Marc Clifton wrote:
if statements are evil.
First they make goto's evil, and now if's? I think it's time for me to retire. :sigh:
Robert Surtees wrote:
First they make goto's evil, and now if's? I think it's time for me to retire.
I'm actually of the mind that gotos are less evil than if's. An if statement results in one or more conditional code branches, which is harder to test than an unconditional goto. When I write an if nowadays, I consciously think "what is the else" and "ok, now I have to test BOTH conditions." I end up often looking at a better way to code the routine that doesn't require an if, and surprisingly, a lot of times I find a way. Marc