|
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.
|
|
|
|
|
That makes sense, especially given the type of algorithms you deal with in parsers and data structures.
In the course of developing several large, complex applications, I've learned that having pieces of code that must stay in sync logically or follow the same algorithm is a failure point. Refactoring can help if i makes sense to move things into a method, and then have each location invoke the method. The hard part there can be figuring out a name for the thing: "CheckToSeeIfMessageNeededAtThreadExit" is ugly  .
Software Zen: delete this;
|
|
|
|
|
right. Extract Method is one of my favorite refactoring tools
I don't use incredibly long names for private methods. I'll abbreviate something like the above to _CheckMessageThread()
Public members i usually go all out, and give it a really long name if it needs one.
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.
|
|
|
|
|
Yours is BS because it will execute everything after the if.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
It was sample code. Normally you'd account for that when you put actual code in there, but without putting anything in there, it's not for me to know where the actual break should happen. However, it was sort of written with the idea that it would follow the main loop logic, kind of like the break example would.
Of course the control flow is slightly different, but it's not irreconcilably different.
if you need something to go after the conditional check, you'd wrap whatever went after the break in the one example in an else block instead.
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.
|
|
|
|
|
Yeas it the simpliest possible 5 lines code. In real life you would probably have another couple of hundreds lines of similar mess entagled there, with some poor soul wondering why is this piece of crap executing when it was not supposed to.
modified 20-Oct-19 21:02pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
