To loop or not to loop?
-
Missing the purpose of the loop:
bool firstTime = true;
foreach (obj x in collection)
{
if (firstTime)
{
[code not referencing "x" in any way at all]
firstTime = false;
}[code referencing "x"]}
Wouldn't want to "check collection.Count" before the loop. No. Silly talk, that.
-
Yes, they are morons.
Haven't they heard of the For-Case paradigm? Much better to handle this.
-
@Poultine said:
Missing the purpose of the loop:
bool firstTime = true;
foreach (obj x in collection)
{
if (firstTime)
{
[code not referencing "x" in any way at all]
firstTime = false;
}[code referencing "x"]}
Wouldn't want to "check collection.Count" before the loop. No. Silly talk, that.
I use similar constructs like this all the time. Often i need to do some kind of initaition at the beginning of the loop, and I use boolean logic to control the first pass through the loop. You may ask why put it in the loop at all, because I only want the code to execute if there is anything within the loop. It has a lot to do with context.
-
Hence check collection.Count.
As in,
if (collection.Count() > 0) {
// code not referencing any elements of the loop
foreach (obj x in collection) {
// code referencing "x"
}
}
Same effect, ten times easier for the maintainer to figure out.
-
Although this version is undeniably senseless, I do tend to use this the other way around, ie if there's something I wish to do for every element except the first one:
bool first = true; StringBuilder result = new StringBuilder(); foreach( string x in collection ) { if( first ) first = false; else result.Append(", "); result.Append(x); }
-
@Iago said:
Hence check collection.Count.
As in,
if (collection.Count() > 0) {
// code not referencing any elements of the loop
foreach (obj x in collection) {
// code referencing "x"
}
}
Same effect, ten times easier for the maintainer to figure out.not quite. What if the conditional is not dependent JUST on the counter?
-
Why possibly iterate through the collection to get a count?
-
@headhigh said:
Why possibly iterate through the collection to get a count?
?????
You do have to watch out for classes where things like "count" are implemented by walking the whole goddam class, like the linked lists they have you make in school. (A paradigm some students unfortunately take to heart.) Might waste a whole 4 bytes, can't have that.
-
@foxyshadis said:
@headhigh said:
Why possibly iterate through the collection to get a count?
?????
You
do have to watch out for classes where things like "count" are
implemented by walking the whole goddam class, like the linked lists
they have you make in school. (A paradigm some students unfortunately
take to heart.) Might waste a whole 4 bytes, can't have that.
Well, you don't know how Count is implemented. At least not typically.
Most collection interfaces contain an isEmpty method, or similar, so the whole point is that code like this:
if (collection.Count() == 0) {...
}
Should really be written as:
if (collection.isEmpty()) {...}
Unless you really want to know how many elements there are, you shouldn't ask...
Btw. do you know what time it is?
-
Did anyone stop to think that maybe the "collection" was only IEnumerable and didn't have the ICollection.Count property? Of course, I would use the following trick for that:
IEnumerator enu = collection.GetEnumerator()
if (enu.MoveNext())
{
[code to do if the collection isn't empty]
}
-
@foxyshadis said:
You do have to watch out for classes where things like "count" are implemented by walking the whole goddam class, like the linked lists they have you make in school. (A paradigm some students unfortunately take to heart.) Might waste a whole 4 bytes, can't have that.
I assume that you're talking about having a counter in the list that would be updated as you insert and remove stuff from it.
The problem with this is that while it turns counting elements into a constant operation instead of a linear one, it also prevent to implement other useful linked list operations (like spliting the list, extracting a sublist, etc.) in O(1).
That's why the STL list, for instance, doesn't have a counter. It's easier to make your own subclass and the counter if you need it if you don't care about splitting, than the other way around.
