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
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:
-
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
-
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
-
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.
Yes, always an early return. Don't futz around with loops: the programmer's expectation is that there are at least some circumstances where the loop will be executed at least once. It's basically trying to avoid two programming taboos, drummed into us by the idiots we call professors: single entry, single exit; and that goto is evil. Neither are correct.
DoEvents: Generating unexpected recursion since 1991
-
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
lol -- probably should have used a smiley instead of a sigh. Reducing complexity is always a Good Thing.
-
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'd place the shorter block first so that you don't have to scroll down to check for the existence of an
elseclause. Of course, this assumes (as you mentioned) that your decision is isn't driven by the need to have positive logic in theiftest. /raviThis is your brain on Celcius Home | Music | Articles | Freeware ravib(at)ravib(dot)com
-
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
Andy Brummer wrote:
I agree with you about that do while crap. Ugh.
Aaarghhh!!! :omg: :wtf: I found it in "Coding Horrors", and it was not supposed to be the "horror": http://www.codeproject.com/Feature/CodingHorrors.aspx?msg=2323029#xx2323029xx[^]
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.
Actually, that's not horrible at all. It's a very slick and elegant way to handle the problem. I used to use this form: #define EVER ;; for(EVER) { if (blah) break; ... break; } Your co-workers solution solves the problem of accidentally forgetting the final break (which i've been bit by a few times). I don't really call that "jumping through hoops" though, It's a pretty common pattern, therefore programmers will expect it. The "one entrance, one exit" rule was put in place because it encourages simplification of the code. Lots of returns within code is often a symptom of overly complex code. It's easier to just return than to clean up after yourself.
-- Where are we going? And why am I in this handbasket?
-
So do I, but definitely not in code blocs.
My head asplode!
Calling all South African developers! Your participation in this local dev community will be mutually beneficial, to you and us.
-
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 don't do it by size of the code block. I do it according to the result of the
ifstatement. I do the "true" result first, and the "false" result second."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 -
Actually, that's not horrible at all. It's a very slick and elegant way to handle the problem. I used to use this form: #define EVER ;; for(EVER) { if (blah) break; ... break; } Your co-workers solution solves the problem of accidentally forgetting the final break (which i've been bit by a few times). I don't really call that "jumping through hoops" though, It's a pretty common pattern, therefore programmers will expect it. The "one entrance, one exit" rule was put in place because it encourages simplification of the code. Lots of returns within code is often a symptom of overly complex code. It's easier to just return than to clean up after yourself.
-- Where are we going? And why am I in this handbasket?
Fair enough. Cheers,
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
