for those of you purists that don't like break, continue and goto
-
Why does it matter?
Wrong is evil and must be defeated. - Jeff Ello
if it matters enough to be a purist about it, then i think it matters. if it doesn't matter to you, you're not a purist about it. :laugh: bow before my tautology!
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
Because
breakis a lot clearer - and less likely to cause problems later if theforloop end condition gets modified.Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
rather my point. sometimes you need a good break, continue, or even a goto (though the latter i typically reserve for generated state machines)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
why do this?
for(int i = 0;i
instead offor(int i = 0;i
hengh?? why you still use break?
:laugh:
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
My personal preference is to use the
break, as when later on when someone adds more logic before that final brace you now have potentially undesirable side effects with having mutatediwithin the loop. I can see the possibility of arguing it either way.“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
if it matters enough to be a purist about it, then i think it matters. if it doesn't matter to you, you're not a purist about it. :laugh: bow before my tautology!
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
I bow before thee my Goodwife CodeWitch. I'm not a purist in this matter, but I still agree with Griff though.
Wrong is evil and must be defeated. - Jeff Ello
-
Because
breakis a lot clearer - and less likely to cause problems later if theforloop end condition gets modified.Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
My personal preference is to use the
break, as when later on when someone adds more logic before that final brace you now have potentially undesirable side effects with having mutatediwithin the loop. I can see the possibility of arguing it either way.“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
GuyThiebaut wrote:
I can see the possibility of arguing it either way.
My guess is that would put you in the minority. As for me, I prefer the break, but then I have no qualms about continue, return, goto, or other "out of band" control flow - pretty much except "throw" which I never use as a control flow statement (though I've been forced to use catch for that occasionally due to Other People's Code - *sideeyes Microsoft's HttpWebRequest class*) i just try to keep the out of band stuff near the top of my scope where people can see it.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I bow before thee my Goodwife CodeWitch. I'm not a purist in this matter, but I still agree with Griff though.
Wrong is evil and must be defeated. - Jeff Ello
I do as well, but then i have no qualms about any out of band control flow statements except throw. It's all in how and where you use them, IMO.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
throwwould be even more clear, definite and failure proof. (well I do see many kids using exactly that to 'not usegoto endlabel')Message Signature (Click to edit ->)
throw is worse than goto, IMO for control flow.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
rather my point. sometimes you need a good break, continue, or even a goto (though the latter i typically reserve for generated state machines)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
I love goto. Lets go-back-to VB. :-D I've made use of gotos to a great extent during my VB times. like, On Error: GoTo the magical origin of the universe. An equally 'powerful' instruction - JMP. But JMP is never ashamed of being JMP, cuz it's assembly. You can go roam anywhere you want, it's got the license. :laugh:
-
I do as well, but then i have no qualms about any out of band control flow statements except throw. It's all in how and where you use them, IMO.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Throw doesn't belong to the control flow. Oh, maybe I'm a bit purist after all.
Wrong is evil and must be defeated. - Jeff Ello
-
I love goto. Lets go-back-to VB. :-D I've made use of gotos to a great extent during my VB times. like, On Error: GoTo the magical origin of the universe. An equally 'powerful' instruction - JMP. But JMP is never ashamed of being JMP, cuz it's assembly. You can go roam anywhere you want, it's got the license. :laugh:
ugh, VB. I use goto in some of my code. Perfectly acceptable place to use GOTO - generated state machine code:
public static bool AcceptsByte(Grimoire.ParseContext pc)
{
pc.EnsureStarted();
if (-1 == pc.Current) return false;
if ((48 == pc.Current))
{
pc.Advance();
goto AcceptsByte_s1;
}
if ((49 == pc.Current))
{
pc.Advance();
goto AcceptsByte_s2;
}
if ((50 == pc.Current))
{
pc.Advance();
goto AcceptsByte_s4;
}
if ((51 <= pc.Current && 57 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s3;
}
return false;
AcceptsByte_s1:
if (-1 == pc.Current) return true;
return -1 == pc.Advance();
AcceptsByte_s2:
if (-1 == pc.Current) return true;
if ((48 <= pc.Current && 57 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s3;
}
return -1 == pc.Advance();
AcceptsByte_s3:
if (-1 == pc.Current) return true;
if ((48 <= pc.Current && 57 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s1;
}
return -1 == pc.Advance();
AcceptsByte_s4:
if (-1 == pc.Current) return true;
if ((48 <= pc.Current && 52 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s3;
}
if ((53 == pc.Current))
{
pc.Advance();
goto AcceptsByte_s5;
}
if ((54 <= pc.Current && 57 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s1;
}
return -1 == pc.Advance();
AcceptsByte_s5:
if (-1 == pc.Current) return true;
if ((48 <= pc.Current && 52 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s1;
}
return -1 == pc.Advance();
}but then I wouldn't write that code by hand. Too error prone.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
Throw doesn't belong to the control flow. Oh, maybe I'm a bit purist after all.
Wrong is evil and must be defeated. - Jeff Ello
i mean, i agree that it shouldn't, but it causes control flow changes and can be used that way. but like i said, i agree. Just because you can do something, doesn't mean you should.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
GuyThiebaut wrote:
I can see the possibility of arguing it either way.
My guess is that would put you in the minority. As for me, I prefer the break, but then I have no qualms about continue, return, goto, or other "out of band" control flow - pretty much except "throw" which I never use as a control flow statement (though I've been forced to use catch for that occasionally due to Other People's Code - *sideeyes Microsoft's HttpWebRequest class*) i just try to keep the out of band stuff near the top of my scope where people can see it.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
GuyThiebaut wrote:
I can see the possibility of arguing it either way.
My guess is that would put you in the minority. As for me, I prefer the break, but then I have no qualms about continue, return, goto, or other "out of band" control flow - pretty much except "throw" which I never use as a control flow statement (though I've been forced to use catch for that occasionally due to Other People's Code - *sideeyes Microsoft's HttpWebRequest class*) i just try to keep the out of band stuff near the top of my scope where people can see it.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
honey the codewitch wrote:
My guess is that would put you in the minority.
I agree, my experience is that as a generalisation us developers have very strong opinions. At the age of 49 I have found that I no longer have the desire to get into arguments over this sort of thing - as in six months time the 'best practise' recommendation will in all likelihood have switched.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
If you enjoy pain try mixing throw with interop. (sure way to properly destroy documents and pst files.)
Message Signature (Click to edit ->)
oooh. Another place i like to throw is in static constructors, just to get absolutely everyone's BAC up. :laugh: I'm kidding. I'm not a sadist.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
why do this?
for(int i = 0;i
instead offor(int i = 0;i
hengh?? why you still use break?
:laugh:
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
honey the codewitch wrote:
My guess is that would put you in the minority.
I agree, my experience is that as a generalisation us developers have very strong opinions. At the age of 49 I have found that I no longer have the desire to get into arguments over this sort of thing - as in six months time the 'best practise' recommendation will in all likelihood have switched.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
an ironic amen to that. I'm a bit younger, but grew tired of the holy rolling, compounded with me leaving the field and no longer being required to write "team" code, I can just do my own thing As a result I've become a bit more buddhist when it comes to most things coding. There are still certain hills I'll die on though, I admit.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
ugh, VB. I use goto in some of my code. Perfectly acceptable place to use GOTO - generated state machine code:
public static bool AcceptsByte(Grimoire.ParseContext pc)
{
pc.EnsureStarted();
if (-1 == pc.Current) return false;
if ((48 == pc.Current))
{
pc.Advance();
goto AcceptsByte_s1;
}
if ((49 == pc.Current))
{
pc.Advance();
goto AcceptsByte_s2;
}
if ((50 == pc.Current))
{
pc.Advance();
goto AcceptsByte_s4;
}
if ((51 <= pc.Current && 57 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s3;
}
return false;
AcceptsByte_s1:
if (-1 == pc.Current) return true;
return -1 == pc.Advance();
AcceptsByte_s2:
if (-1 == pc.Current) return true;
if ((48 <= pc.Current && 57 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s3;
}
return -1 == pc.Advance();
AcceptsByte_s3:
if (-1 == pc.Current) return true;
if ((48 <= pc.Current && 57 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s1;
}
return -1 == pc.Advance();
AcceptsByte_s4:
if (-1 == pc.Current) return true;
if ((48 <= pc.Current && 52 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s3;
}
if ((53 == pc.Current))
{
pc.Advance();
goto AcceptsByte_s5;
}
if ((54 <= pc.Current && 57 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s1;
}
return -1 == pc.Advance();
AcceptsByte_s5:
if (-1 == pc.Current) return true;
if ((48 <= pc.Current && 52 >= pc.Current))
{
pc.Advance();
goto AcceptsByte_s1;
}
return -1 == pc.Advance();
}but then I wouldn't write that code by hand. Too error prone.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
what's cool about that code though? It's directly translatable from visual graphs of the state objects it represents. I use graphviz to visualize them, and you can see right in the graph where the code matches up. It's beautiful - a 1:1 translation. So the code actually is human readable, you just need the map (the visual graph) for it.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
i mean, i agree that it shouldn't, but it causes control flow changes and can be used that way. but like i said, i agree. Just because you can do something, doesn't mean you should.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
I've seen MS themselves doing it. Sometimes when external code that you don't have control over lacks certain functionality, it might be your only choice. (been there, done that. X| )
Wrong is evil and must be defeated. - Jeff Ello
