Best Practices for Linq Enumerables and Queryables
code.jonwagner.com
Best Practices for Linq Enumerables and Queryables
1–10 of 30 posts
Re: Best Practices for Linq Enumerables and Queryables
#2Good to see some C# on HN
Re: Best Practices for Linq Enumerables and Queryables
#3It 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 execution is deferred. And yes, you have to understand this deferred execution and how it affects your code. But his code example is TERRIBLE.
var allCustomers = customers; var waCustomers = allCustomers.Where (c => c.Region == "WA"); var waCustomerIDs = waCustomers.Select (c => c.ID);
Why copy the variable to allCustomers? And if you need Id and name, you can write code like this:
var customerIdAndNames = from c in customers where c.Region.Equals("WA", StringComparison.OrdinalIgnoreCase) select new { ID = c.ID, Name = c.Name };
There was absolutely no reason to create two different IEnumerables for a scenario where you needed different properties.
3. Again, one has to understand that result of a query is just that, a 'query'. And you don't have to call 'ToList' method to execute the query. In fact, if you want to iterate the query results only once, it's better to use foreach and enumerate over the query results instead of calling ToList method as you will be not have to consume memory to store the entire list.
4. Horrible idea to suggest that you should always return List instead of IEnumerable. This choice should be left up to API caller in most cases.
This whole article is garbage. It is OPPOSITE of best practices in LINQ.
Re: Best Practices for Linq Enumerables and Queryables
#4It 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.
Re: Best Practices for Linq Enumerables and Queryables
#5It 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…
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");
var males = from c in customers where c == "male" select c;
Re: Best Practices for Linq Enumerables and Queryables
#6It 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 embraced, not hidden away and overriden. Should we also not bother with the yield keyword?
Of course, there's always some occasion where you'll want to ToList your IEnumerable. I'd argue this should be of concern to the consumer of the IEnumerable though, not the producer.
Point 5 at least tries to allude to something useful. Given Linq's grounding in functional programming, of course you want to try to avoid side effects.
Re: Best Practices for Linq Enumerables and Queryables
#7It 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 prefer using extension methods over query syntax; I personally find extension methods easier to read. I guess it's a matter of personal preference.
Re: Best Practices for Linq Enumerables and Queryables
#8"Sealing the chain" as you say, is indeed important for scenarios such as lookups within a loop. If you haven't .ToList()ed your lookup LINQ var, you will be requerying with every iteration. A simple change that can slow down code dramatically.
Re: Best Practices for Linq Enumerables and Queryables
#9It 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 the let keyword; the following code:
var x = from post in posts
let keywords = post.split(' ')
...
var x = posts
.Select(post => new { keywords = post.split(' '), post })
...
Re: Best Practices for Linq Enumerables and Queryables
#10It 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…
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);
var males = from c in customers where c.IsMale select c;
e.g.
var filteredCustomers =
from c in customers
join o in orders on o.customerid = c.customerid
where c.IsMale && c.Age > 30
where o.IsPending
select new {Customer = c, Order = o};
My point was that the whole purpose of query syntax was to improve readability and it was not about 'pretty' or 'clever'.