Our codebase at work has hundreds if not thousands of LINQ queries, mostly using method syntax. I generally prefer it over query syntax except in a few cases, such when there's multiple joins or subqueries, or the when the statement is more than a few dozen lines. Occasionally a very complex LINQ statement requires using a `let` declaration which also is easier with query syntax. Luckily Resharper has an action to convert back and forth on the fly, so it's easy to use that to switch over when necessary.
I also don't use LINQ to SQL at all. It's all on in-memory stuff. I pretty much never write code like this:
var result = new List<string>();
foreach (var item in input)
{
result.Add(item.Value);
}
return result;
instead, using LINQ:
return items.Select(x => x.Value);
The real power comes when you start mixing conditions:
I think it depends on what the Linq to is. I find the sql like proper linq form only natural when databases are involved (and just barely).
Most uses of where/order/select in C# I'm pretty sure is linq to objects, not sql. I very rarely see the linq proper form in any C# code neither in OSS or in my dat job.
I never use the query syntax, or ever see it in any of the books or blogs I read, to the point that it threw me for a loop a little bit when I was studying for the C# certification exam, to see how emphasized it was. I learned that style long ago when I first started, but the fluent, extension method style is easier and less ugly, IMO, particularly when you start getting into more complex queries, or LINQ-to-SQL, where you end up wrapping your multi-line LINQ query in parentheses and materializing it by calling ToList() or ToDictionary() at the end.
I also don't use LINQ to SQL at all. It's all on in-memory stuff. I pretty much never write code like this:
instead, using LINQ: The real power comes when you start mixing conditions: Or doing quick checks: