|
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. 
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.
|
|
|
|
|
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.
|
|
|
|
|
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.  )
|
|
|
|
|
right? that's why i *never* throw!
kidding!
but in seriousness I take great pains to prevent the users of my code from having to catch exceptions on failure if they don't want them.
Like I'll provide TryXXXX to complement XXXX
Pck: Code Roundup and Quick Start Guide[^]
In PCK I have an elaborate error handling system whereby it finds errors and continues processing only (optionally) throwing an exception at the end with ALL the errors it encountered.
Otherwise they're reported as "messages" with different severity/errorlevels
probably the most elaborate exception handling i've had to do in managed code.
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 break is a lot clearer - and less likely to cause problems later if the for loop 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.
|
|
|
|
|
I love goto. Lets go-back-to VB.  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.
|
|
|
|
|
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.
|
|
|
|
|
Yep, goto on a lengthier code is definitely not meant for the human eyes. 
|
|
|
|
|
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.
|
|
|
|
|
Quote: but then I wouldn't write that code by hand. Too error prone.
Isn't this exactly the point? All code gets compiled/interpreted/translated to jmps eventually.
The goals of the written code should be correctness, understandability and simplicity.
Leave the gotos and the clever techniques to the compiler.
|
|
|
|
|
You trust your compiler?? Wow!
|
|
|
|
|
I'll optimize when i need to. that doesn't always make the code readable.
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.
|
|
|
|
|
The reality is that with modern code, it's so far removed from the underlying machine language that gets executed that there's no point trying optimisations at the level of a break vs setting the iterator.
Optimisations nowadays are at architectural levels - managing tight loops, using appropriate data structures, parallelisation, resource access.
|
|
|
|
|
yes and no. it depends on whether you consider algorithmic optimizations to be architecture.
For example, my first crack at LALR(1) table generation was taking 5 minutes to generate the tables for javascript.
My second one cut that to a 5th of the time.
The cost was code that was no longer "pure" and readable.
It wasn't an architecture change. Unless you think it was. But I wouldn't agree, and I wrote 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.
|
|
|
|
|
throw would be even more clear, definite and failure proof.
(well I do see many kids using exactly that to 'not use goto 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.
|
|
|
|
|
If finding the desired value is exceptional and unexpected and requiring special handling, then throwing an exception is appropriate.
If it is the normal and desired case, exeactly what you expected: "Yeah, there it is!", then an exception is not the right mechanism.
|
|
|
|
|
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 mutated i within 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.
|
|
|
|
|
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. 
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
