|
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.
|
|
|
|
|
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.
|
|
|
|
|
At times, the purpose of the search might be just to find the index of the valueToFind. Break keeps the index safe?
(JS)
var arr =[0,1,2,3,4,5];
var valueToFind = 3;
for(i=0;i<arr.length;i++)
{
if(arr[i]==valueToFind)
{
break;
}
}
console.log(i);
Then go on to calculate an offset or something from this index.
modified 14-Sep-19 11:38am.
|
|
|
|
|
right, but in the OP i limited i to the loop scope, but yeah.
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 code is hard to write, it should be hard to read.
i'm a sucker for symmetry.
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 have even encountered this in pseudocode, where the author could easily have added a break to his made-up exposition-purposes-only language but chose a more obfuscated way instead.
|
|
|
|
|
I prefer break statements. It is not suitable for big projects it might be confusing. I try my level best to write clean code!
|
|
|
|
|
Because the second fragment duplicates knowledge of the loop's termination condition. You have to remember to adjust it in two places. The first fragment is therefore more robust.
Software Zen: delete this;
|
|
|
|
|
yep. although there are cases where I'll modify i inside the loop for other reasons. Like if I have to add or remove items while enumerating (it happens with complicated algos)
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
