[kstr]

How can i do this better /quicker:

  List<string> ids = new List<string>();
                foreach (Product pr in products)
                {
                    foreach (ProductVariant pv in pr.ProductVariants)
                    {
                        ids.Add(pv.ManufacturerPartNumber);
                    }
                }

[tlhIn`toq]

You might be able to do it in a single line or two in Linq.
But I don't think that would be any 'better' or 'faster' since it is really going to have to be a couple loops anyway, just hidden away in the Framework where the coder doesn't see it.

What makes you think there is something wrong with the way you are doing it now?

[Curtis Rutland]

Well, you could do it with LINQ:

var ids = products.Select(pr => pr.ManufacturerPartNumber).ToList();

Assuming you're using .NET 3.5 or higher, and you have add using System.Linq; to the using directives.

[kstr]

tlhIn`toq, on 16 March 2011 - 11:22 AM, said:

You might be able to do it in a single line or two in Linq.
But I don't think that would be any 'better' or 'faster' since it is really going to have to be a couple loops anyway, just hidden away in the Framework where the coder doesn't see it.

What makes you think there is something wrong with the way you are doing it now?

Well while i was writing it, i got an eery feeling about it

It seemed not 'best practice' to iterate in a nested way like that.

[tlhIn`toq]

That's probably what loops do 99% of the time: Iterate through a list or collection of something.

Nested loops you see allot for either x,y data structures or for hierarchical structures. So you're using it as it was intended.

[kstr]

insertAlias, on 16 March 2011 - 11:26 AM, said:

Well, you could do it with LINQ:

var ids = products.Select(pr => pr.ManufacturerPartNumber).ToList();

Assuming you're using .NET 3.5 or higher, and you have add using System.Linq; to the using directives.

yes, but i still have to select all productvariants and then select among then?

[Curtis Rutland]

Didn't notice the nesting. My LINQ wouldn't work there. But there's nothing explicitly wrong with nested foreach loops. It's O(n²), but that's the best that can be hoped for with that kind of operation.

You still can do this with LINQ though:

var ids = products.SelectMany(x => x.ProductVariants).Select(x => x.ManufacturerPartNumber).ToList();

But the operation is no faster. Select and SelectMany are just obfuscating loops.

[kstr]

Ok thanks a lot

[ragingben]

I like LINQ, but I think that sometimes spreading code over a few lines like the OP code is preferable just because it is so easy to understand for anyone looking at it, especially those migrating from other languages, which in commerical applications is vital.

[AdamSpeight2008]

Here you go,
LINQ statements over multiple lines.

var ids = products
          .SelectMany(Product => Product.ProductVariants)
          .Select(ProductVariant => ProductVariant.ManufacturerPartNumber)
          .ToList()

Maybe it is x. that makes it harder to understand.

This post has been edited by AdamSpeight2008: 17 March 2011 - 06:06 AM

[Curtis Rutland]

x is a bad habit of mine. Lots of examples out there used it, so I picked it up as a habit, and it stuck. More descriptive names are better, but it's just what naturally comes to me as I write the query.

[eclipsed4utoo]

insertAlias, on 17 March 2011 - 10:43 AM, said:

x is a bad habit of mine. Lots of examples out there used it, so I picked it up as a habit, and it stuck. More descriptive names are better, but it's just what naturally comes to me as I write the query.

I don't see it as a bad habit. That's like saying using i in a for loop is bad.

Though I don't normally use the same letter in multiple, connected LINQ statements. Like I use t all the time, but in your example, I would have probably used t and s instead of t twice.

[AdamSpeight2008]

Using different and proper names is preferred. As x is both lambda function are different and independent variables. They are also are of different types.

[tlhIn`toq]

Not to mention that most controls have an X property as part of their .Location property. I would just avoid using 'x' all together unless I really meant someObject.Location.X

And really, when it comes to readability/maintainability myFoundResults is a variable I would rather come across in code a year from now than x.

Last I checked there was no shortage of Unicode or ASCII characters and we aren't paying for variable names by the byte.

This post has been edited by tlhIn`toq: 17 March 2011 - 08:35 AM

[Curtis Rutland]

Well, in my defense, x would only be used inside a single-line lambda, and it would be a variable name, not a property. Also, LINQ queries are supposed to be concise. That's a major point of LINQ; brevity. So having a long character variable name as an iterator variable wouldn't make any sense, just like you don't do for(int myIteratorForLoop = 1....

I think a middle ground is better. Single letters aren't bad for simple LINQ queries, but repeating the same one probably is confusing.

This post has been edited by insertAlias: 17 March 2011 - 08:52 AM