Best Practices for Linq Enumerables and Queryables

  var thing = 
    from x in stuff
    let derp = x.herp
    select { x.name }

  var thing = stuff.Select( x => {
    var derp = x.herp;

    return new { x.name };
  } );

I think each have their place, but this absolutely enrages me:

  var things = ( from x in thingList select x ).ToList()

Perhaps, it really depends. One nice advantage that returning IEnumerable has over returning List is that it gives better flexibility and maintainability.

If you return List, you're tying yourself to that specific class now and forever. Any change will be a breaking change.

If you return IEnumerable, all you're guaranteeing is that you'll return something that the caller can enumerate over to get their data. Meaning if you later discover that you have some compelling reason to switch to using a HashSet internally, and that it would also be most convenient if you could just pass back that HashSet, well, there's nothing to stop you.

You don't get that flexibility by typing your return value as List because you've tied yourself to that specific class. You also don't get that flexibility by passing back IList. IList defines an ordered, positionally-indexed collection, and hashes are not that. ICollection might work, but it defines an interface for a mutable collection, which might also be a restriction you don't want to commit to now and forever.

So in general it's best to pass back the most flexible type you can. Partially because YAGNI, but mostly because trying to create a pit of success for your users doesn't mean you can't also try to create a pit of success for yourself as well.

(Forgot to mention - the semantics that you're claiming for IEnumerable doesn't really line up with how it's actually used. IEnumerable has been around since .NET 1.1, and IEnumerable has been around since .NET 2.0. There were years and years where IEnumerable simply defined an object that could be enumerated before LINQ came on the scene and introduced us to ubiquitous examples of lazily-generated IEnumerables, or introduced all these useful extension methods that take IEnumerable and return a lazily-generated IEnumerable.)

Consider var query = (from customer in context.Customers select customer).ToList().Where( c => c.Id == 3);

vs var query = (from customer in context.Customers where customer.Id == 3 select customer);

The first LINQ query results in "SELECT * FROM customer". The WHERE clause is applied after the result set is returned. The second generates a real WHERE clause. The result set is filter on the server before being sent to the client.

Exactly. Most of the advice in the article is sensible when viewed from that perspective.

I use LINQ to Entity in my company's service API. If you fail to "seal" the query (as he calls it) with ToList() before you leave the 'using' block for your DB context, your callers get a runtime error later since the IQueryable isn't run until the caller enumerates it (i.e. after the 'using' block has disposed the DB context). (On the other hand, if you call ToList() too early in your method chain, you're preventing L2E from composing your expression tree into optimal SQL, since everything after ToList() is run client-side.)

As an API provider you have to treat the behavior of your return values as part of the contract, and if your caller is expecting a plain IEnumerable (like you claim to return in your method signature), you'd best make sure it isn't really an IEnumerableThatDependsOnNondeterministicContext or an IEnumerableWithUnpredictableSideEffects.

His point is spot on about returning IQueryable only when your intention is for the caller to compose your result with other queries. If you're just returning an IQueryable because you think it's cool to defer execution, you're probably missing the point. Deferred execution isn't 100% win; you can just as easily defer yourself into a timeslot when there's more contention for a resource as into one where there's less contention. In many cases it's just as well to declare your need for the data (e.g. by calling ToList() as early as possible and let the system manage the execution.