Best Practices for Linq Enumerables and Queryables • Hacker News Board

Re: Best Practices for Linq Enumerables and Queryables

#11

Post by [deleted] » Fri, Aug 24, 2012, 3:38 PM UTC

upthedale wrote: post #6

solutionyogi wrote: post #3

It is a terrible article. 1. Why would the author recommend using extension method instead of using the 'query' syntax? The main purpose behind creating the query syntax was to make your code easier to read. Query syntax is not at all about 'pretty' or 'clever'. It's about readability. [And why call the query syntax as 'language extension'?] 2. Why invent terms like 'seal' LINQ queries? By default, all LINQ querie ex…

Absolutely. You saved me writing the same thing. Regarding point 1, I would add there are also things that can be done using the query syntax that simply can't with the extension methods. For instance, I'm not sure how you would scope things in the same way as the 'let' clause when using extension methods. Regarding the other points, I would only add that deferred execution and lazy evaluation are things to be embrac…

[deleted]

Re: Best Practices for Linq Enumerables and Queryables

#12

Post by stephenfung » Fri, Aug 24, 2012, 3:39 PM UTC

The article does a good job of exposing common pitfalls to those new to deferred execution and offers some solid advice. However, I agree that it's overly defensive to recommend ToList'ing almost every IEnumerable to avoid having to think about it, but this seems like a decent idea for more "software conservative" developers.

Re: Best Practices for Linq Enumerables and Queryables

#13

Post by solutionyogi » Fri, Aug 24, 2012, 3:39 PM UTC

upthedale wrote: post #6

solutionyogi wrote: post #3

It is a terrible article. 1. Why would the author recommend using extension method instead of using the 'query' syntax? The main purpose behind creating the query syntax was to make your code easier to read. Query syntax is not at all about 'pretty' or 'clever'. It's about readability. [And why call the query syntax as 'language extension'?] 2. Why invent terms like 'seal' LINQ queries? By default, all LINQ querie ex…

Absolutely. You saved me writing the same thing. Regarding point 1, I would add there are also things that can be done using the query syntax that simply can't with the extension methods. For instance, I'm not sure how you would scope things in the same way as the 'let' clause when using extension methods. Regarding the other points, I would only add that deferred execution and lazy evaluation are things to be embrac…

Yes, Eric Lippert, principal developer of C# compiler, has been drumming for a long time that query should never have a side effect. It should be about filtering and sorting the data. See: http://blogs.msdn.com/b/ericlippert/archive/2009/05/18/forea...

Re: Best Practices for Linq Enumerables and Queryables

#14

Post by upthedale » Fri, Aug 24, 2012, 3:40 PM UTC

SimonB86 wrote: post #9

upthedale wrote: post #6

Earlier quoted context omitted.

Absolutely. You saved me writing the same thing. Regarding point 1, I would add there are also things that can be done using the query syntax that simply can't with the extension methods. For instance, I'm not sure how you would scope things in the same way as the 'let' clause when using extension methods. Regarding the other points, I would only add that deferred execution and lazy evaluation are things to be embrac…

Regarding the let keyword; the following code: var x = from post in posts let keywords = post.split(' ') ... Is compiled* into: var x = posts .Select(post => new { keywords = post.split(' '), post }) ... * If you didn't know already, the compiler transforms query syntax into extension method syntax.

Oh yes, I did actually realise that. Thank you though.

I worded it badly. I should have been clearer in that I was following on from solutionyogi's argument about readability.

The compiler example is a bit on the ugly side, wouldn't you say? To then access 'keywords', it becomes

  ...
  .Where(anon => anon.keywords[0] == "verybadexample")
  .Select(anon => anon.post);

What I should have said was that I'm not sure how you would scope things in the same way as the 'let' clause when using extension methods with the same level of readability.

Re: Best Practices for Linq Enumerables and Queryables

#15

Post by bunderbunder » Fri, Aug 24, 2012, 3:48 PM UTC

upthedale wrote: post #6

solutionyogi wrote: post #3

It is a terrible article. 1. Why would the author recommend using extension method instead of using the 'query' syntax? The main purpose behind creating the query syntax was to make your code easier to read. Query syntax is not at all about 'pretty' or 'clever'. It's about readability. [And why call the query syntax as 'language extension'?] 2. Why invent terms like 'seal' LINQ queries? By default, all LINQ querie ex…

Absolutely. You saved me writing the same thing. Regarding point 1, I would add there are also things that can be done using the query syntax that simply can't with the extension methods. For instance, I'm not sure how you would scope things in the same way as the 'let' clause when using extension methods. Regarding the other points, I would only add that deferred execution and lazy evaluation are things to be embrac…

Regarding point 1, I would add there are also things that can be done using the query syntax that simply can't with the extension methods.

Quite the opposite. Everything in the query syntax gets translated into method calls, even if the way in which it is done so is sometimes non-obvious.[1] However, there are a lot of extension methods that don't have an equivalent in the query syntax - many of the aggregation functions, for example.

[1]:http://stackoverflow.com/questions/1092687/code-equivalent-t...

Re: Best Practices for Linq Enumerables and Queryables

#16

Post by [deleted] » Fri, Aug 24, 2012, 3:56 PM UTC

solutionyogi wrote: post #10

dmiranda wrote: post #5

Earlier quoted context omitted.

About your first point, sometimes using method syntax is more readable than query. When you are not reliying heavily on LINQ and just use some commands, is easier to write var males = customers.Where(c => c.Gender == "male"); than var males = from c in customers where c == "male" select c; Not only because it's longer, but also because it can feel strange if you're not using it continously.

Readability is definitely subjective. For simple scenarios, I do prefer the extension method. E.g. in my code, it would actually be like var males = customers.Where(c => c.IsMale); vs var males = from c in customers where c.IsMale select c; But often, queries are not that simple and in such scenario query syntax offers far more readability: e.g. var filteredCustomers = from c in customers join o in orders on o.custom…

[deleted]

Re: Best Practices for Linq Enumerables and Queryables

#17

Post by redstripe » Fri, Aug 24, 2012, 4:00 PM UTC

solutionyogi wrote: post #10

dmiranda wrote: post #5

Earlier quoted context omitted.

About your first point, sometimes using method syntax is more readable than query. When you are not reliying heavily on LINQ and just use some commands, is easier to write var males = customers.Where(c => c.Gender == "male"); than var males = from c in customers where c == "male" select c; Not only because it's longer, but also because it can feel strange if you're not using it continously.

Readability is definitely subjective. For simple scenarios, I do prefer the extension method. E.g. in my code, it would actually be like var males = customers.Where(c => c.IsMale); vs var males = from c in customers where c.IsMale select c; But often, queries are not that simple and in such scenario query syntax offers far more readability: e.g. var filteredCustomers = from c in customers join o in orders on o.custom…

Assuming you have a foreign key set up between customers and orders, your 'order' entity will automatically have a 'customer' property so you can avoid the 'join' syntax.

If your objective is to find orders that belong to male customers over 30:

filteredCustomers = orders.Where(o => o.IsPending && o.customer.IsMale && o.customer.Age > 30);

Some more about avoiding joins (which makes it easier to use the extension syntax): http://blogs.teamb.com/craigstuntz/2010/01/13/38525/

Re: Best Practices for Linq Enumerables and Queryables

#18

Post by bunderbunder » Fri, Aug 24, 2012, 4:04 PM UTC

aggronn wrote: post #4

solutionyogi wrote: post #3

It is a terrible article. 1. Why would the author recommend using extension method instead of using the 'query' syntax? The main purpose behind creating the query syntax was to make your code easier to read. Query syntax is not at all about 'pretty' or 'clever'. It's about readability. [And why call the query syntax as 'language extension'?] 2. Why invent terms like 'seal' LINQ queries? By default, all LINQ querie ex…

I agree--I'm not sure how he was lead to believe this is best practice. If you mean to process the results of the query with a loop, its silly to enumerate over the query to create a List then enumerate over it again to modify those objects, which sounds like what he's suggesting is best practice.

I think perhaps he is confusing best practices for public interfaces with general-purpose best practices.

It is a good idea to prefer ToList()ing any data you're passing out of a library. An 'open' LINQ query might represent a whole lot of work, and that work will get repeated every time someone re-enumerates the query. And the query might be holding on to any number of resources that the end-user can't know about. Returning a data structure instead of an unexecuted query makes it much easier for people who are working with your library to know what they're working with, because what they're working with is simply the contents of the data structure. To that end, it's preferable according to the "pit of success" principle.

But that flip-flops when you're only dealing with the inside an assembly. None of the concerns listed above really apply in that case, so it's generally preferable to avoid petrifying your LINQ expressions unless you absolutely have to.

Re: Best Practices for Linq Enumerables and Queryables

#19

Post by aggronn » Fri, Aug 24, 2012, 4:25 PM UTC

bunderbunder wrote: post #18

aggronn wrote: post #4

Earlier quoted context omitted.

I agree--I'm not sure how he was lead to believe this is best practice. If you mean to process the results of the query with a loop, its silly to enumerate over the query to create a List then enumerate over it again to modify those objects, which sounds like what he's suggesting is best practice.

I think perhaps he is confusing best practices for public interfaces with general-purpose best practices. It is a good idea to prefer ToList()ing any data you're passing out of a library. An 'open' LINQ query might represent a whole lot of work, and that work will get repeated every time someone re-enumerates the query. And the query might be holding on to any number of resources that the end-user can't know about. R…

Ah, I hadn't been in that situation or thought about that. Makes perfect sense though.

Re: Best Practices for Linq Enumerables and Queryables

#20

Post by upthedale » Fri, Aug 24, 2012, 4:34 PM UTC

bunderbunder wrote: post #18

aggronn wrote: post #4

Earlier quoted context omitted.

I agree--I'm not sure how he was lead to believe this is best practice. If you mean to process the results of the query with a loop, its silly to enumerate over the query to create a List then enumerate over it again to modify those objects, which sounds like what he's suggesting is best practice.

I think perhaps he is confusing best practices for public interfaces with general-purpose best practices. It is a good idea to prefer ToList()ing any data you're passing out of a library. An 'open' LINQ query might represent a whole lot of work, and that work will get repeated every time someone re-enumerates the query. And the query might be holding on to any number of resources that the end-user can't know about. R…

But if you're ToListing it, your return type might as well just be List, not IEnumerable (or IQueryable).

I feel that by declaring your return type as IEnumerable, you're implicitly saying to any caller that the return object is something that can iterate (and potentially generate) through results when requested, and so care should be taken with its use (to avoid getting multiple IEnumerator objects, and iterating unnecessarily).

As I've said elsewhere, this functionality should be embraced.

One of the ways the caller might prevent iterating unnecessarily may be to call ToList or ToArray. Alternatively, they might structure their calling code better. Either way, it should be the caller's choice, instead of being imposed by the underlying method.