for those of you purists that don't like break, continue and goto
-
Depending on the length of the array, just let it loop :D I rarely use break or continue (break slightly more often, but probably only a handful in my entire career). I've never used goto, except to mock you I think :D I'd use FirstOrDefault here (which probably uses a break, I don't know). This kind of functionality is embedded in .NET, so why would I write my own? But if I had to pick, I'd choose the break, which far more clearly communicates intent than i=arr.Length;.
honey the codewitch wrote:
} // braces copyright Sander Rossel
So proud of my honeycode the witch :D
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
if code is hard to write, it should be hard to read. :laugh: 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.
-
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.
-
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
right, but in the OP i limited
ito 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.
-
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.
I prefer break statements. It is not suitable for big projects it might be confusing. I try my level best to write clean code!
-
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.
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; -
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.
-
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.
-
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.
-
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.
:laugh: it's funny cuz it's true. For the record, I'm not endorsing the method i described, I'm simply being facetious about it. I think it's silly. A break statement is much clearer, which was kind of the point of my OP. Sometimes you need break. Or a continue. Or even a goto (which i can give a solid use case for - in this case making the code MORE 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.
-
:laugh: it's funny cuz it's true. For the record, I'm not endorsing the method i described, I'm simply being facetious about it. I think it's silly. A break statement is much clearer, which was kind of the point of my OP. Sometimes you need break. Or a continue. Or even a goto (which i can give a solid use case for - in this case making the code MORE 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.
-
Alright, here a piece of advice: never exit conditionally a for cycle. if you need to do that, use while or do until.
i think it depends on the situation for example
public int IndexOf(T item)
{
var ic = Count;
var i = 0;
for(;iThat's very clear even without comments
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 think it depends on the situation for example
public int IndexOf(T item)
{
var ic = Count;
var i = 0;
for(;iThat's very clear even without comments
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 yeah. That's a little less clear to me though. I avoid do loops usually because the conditional can get confusing if you're used to regular for loops. It takes me a second to work out what's going on, like when exactly the condition exits. It's not big deal, it's just my preference. I think my code is clearer.
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 yeah. That's a little less clear to me though. I avoid do loops usually because the conditional can get confusing if you're used to regular for loops. It takes me a second to work out what's going on, like when exactly the condition exits. It's not big deal, it's just my preference. I think my code is clearer.
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.
It is simpler and I actually use pretty much exactly the same code when it is that simple. When you have more than a page of lines within that loop a sudden exit is not what I would do. And a sudden conditional exit with break or return might be even ok. Putting the i to the max and then exit in that manner is something I would never do.
-
It is simpler and I actually use pretty much exactly the same code when it is that simple. When you have more than a page of lines within that loop a sudden exit is not what I would do. And a sudden conditional exit with break or return might be even ok. Putting the i to the max and then exit in that manner is something I would never do.
well to each their own. probably it also has to do with my C++ background which influences a lot of my code. Not that C++ has different flow constructs, it's just that a) i learned these habits a long time ago and the industry changes b) C++ development is a different animal, and control flow is all over the place generally and for loops are used for almost everything except while(true) although some people go for(;;). It's not uncommon even to do stuff like
for(current=firstNode;null!=current;current=current.nextNode) if(current->key==key) break;to traverse a linked list for example.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. 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 :-D.Software Zen:
delete this; -
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 :-D.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.
-
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.
A purist should be worried about touching control variables. Hmmm.
Jordan
-
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.
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.
