It occurred to me that I write out linq statements in a simple, but what others may define as verbose manner;
A simple example:
return _entries
.Where(x => x.Context.Equals(context))
.Where(x => x.Type == typeof (T))
.Select(x=>x.Value)
.Cast<T>()
.Single();
can be simplified to:
return _entries
.Where(x => x.Context.Equals(context) && x.Type == typeof (T))
.Select(x=>(T)x.Value)
.Single();
[Question] In the long run, which is the better coding practice? i.e. long (and simple) linq chains or short linq chains with more complicated selectors/etc?
It is right to assume that these Linq statements will be optimized by the compiler?
In the long run, which is the better coding practice?
I prefer short and simple. It's more readable. The whole point of LINQ is to make the code read more like the logic of the business domain.
It is right to assume that these Linq statements will be optimized by the compiler?
No; the optimization is done by the runtime, not by the compiler. LINQ-to-objects "Where" and "Select" clauses that follow the pattern you describe are optimized into a single "where-select" object at runtime to avoid creating too many iterators. (Though as Jon Skeet discovered, that can sometimes produce situations in which performance is actually degraded; like almost all "optimizations", it's not a win 100% of the time. Unfortunately I can't find Jon's article on that at this moment.)