Should I use two "where" clauses or "&&" in my LINQ query?

When writing a LINQ query with multiple "and" conditions, should I write a single where clause containing && or multiple where clauses, one for each conditon?

static void Main(string[] args)
{
	var ints = new List<int>(Enumerable.Range(-10, 20));

	var positiveEvensA = from i in ints
                         where (i > 0) && ((i % 2) == 0)
                         select i;

	var positiveEvensB = from i in ints
                         where i > 0
                         where (i % 2) == 0
                         select i;

	System.Diagnostics.Debug.Assert(positiveEvensA.Count() == 
                                         positiveEvensB.Count());
}

Is there any difference other than personal preference or coding style (long lines, readability, etc.) between positiveEvensA and positiveEvensB?

One possible difference that comes to mind is that different LINQ providers may be able to better cope with multiple wheres rather than a more complex expression; is this true?

I personally would always go with the && vs. two where clauses whenever it doesn't make the statement unintelligible.

In your case, it probably won't be noticeble at all, but having 2 where clauses definitely will have a performance impact if you have a large collection, and if you use all of the results from this query. For example, if you call .Count() on the results, or iterate through the entire list, the first where clause will run, creating a new IEnumerable<T> that will be completely enumerated again, with a second delegate.

Chaining the 2 clauses together causes the query to form a single delegate that gets run as the collection is enumerated. This results in one enumeration through the collection and one call to the delegate each time a result is returned.

If you split them, things change. As your first where clause enumerates through the original collection, the second where clause enumerates its results. This causes, potentially (worst case), 2 full enumerations through your collection and 2 delegates called per member, which could mean this statement (theoretically) could take 2x the runtime speed.

If you do decide to use 2 where clauses, placing the more restrictive clause first will help quite a bit, since the second where clause is only run on the elements that pass the first one.

Now, in your case, this won't matter. On a large collection, it could. As a general rule of thumb, I go for:

1. Readability and maintainability

2. Performance

In this case, I think both options are equally maintainable, so I'd go for the more performant option.

This is mostly a personal style issue. Personally, as long as the where clause fits on one line, I group the clauses.

Using multiple wheres will tend to be less performant because it requires an extra delegate invocation for every element that makes it that far. However it's likely to be an insignificant issue and should only be considered if a profiler shows it to be a problem.

The performance issue only applies to memory based collections ... Linq to SQL generates expression trees that defer execution. More Details here:

https://stackoverflow.com/questions/8791540/multiple-where-clauses-with-linq-extension-methods

As Jared Par has already said: it depends on your personal preference, readability and the use-case. For example if your method has some optional parameters and you want to filter a collection if they are given, the Where is perfect:

IEnumerable<SomeClass> matchingItems = allItems;
if(!string.IsNullOrWhiteSpace(name))
    matchingItems = matchingItems
       .Where(c => c.Name == name);
if(date.HasValue)
    matchingItems = matchingItems
       .Where(c => c.Date == date.Value);
if(typeId.HasValue)
    matchingItems = matchingItems
       .Where(c => c.TypeId == typeId.Value);
return matchingItems;

If you wanted to do this with &&, have fun ;)

Where i don't agree with Jared and Reed is the performance issue that multiple Where are supposed to have. Actually Where is optimized in a way that it combines multiple predicates to one as you can see here(in CombinePredicates).

But i wanted to know if it really has no big impact if the collection is large and there are multiple Where which all have to be evaluated. I was suprised that the following benchmark revealed that even the multiple Where approach was slightly more efficient. The summary:

Method	Mean	Error	StdDev
MultipleWhere	1.555 s	0.0310 s	0.0392 s
MultipleAnd	1.571 s	0.0308 s	0.0649 s

Here's the benchmark code, i think it's good enough for this test:

#LINQPad optimize+

void Main()
{
	var summary = BenchmarkRunner.Run<WhereBenchmark>();
}


public class WhereBenchmark
{
	string[] fruits = new string[] { "apple", "mango", "papaya", "banana", "guava", "pineapple" };
	private IList<string> longFruitList;
	
	[GlobalSetup]
	public void Setup()
	{
		Random rnd = new Random();
		int size = 1_000_000;
		longFruitList = new List<string>(size);
		for (int i = 1; i < size; i++)
			longFruitList.Add(GetRandomFruit());

		string GetRandomFruit()
		{
			return fruits[rnd.Next(0, fruits.Length)];
		}
	}


	[Benchmark]
	public void MultipleWhere()
	{
		int count = longFruitList
			.Where(f => f.EndsWith("le"))
			.Where(f => f.Contains("app"))
			.Where(f => f.StartsWith("pine"))
			.Count(); // counting pineapples
	}
	
	[Benchmark]
	public void MultipleAnd()
	{
		int count = longFruitList
			.Where(f => f.EndsWith("le") && f.Contains("app") && f.StartsWith("pine"))
			.Count(); // counting pineapples
	}
}

If you run SQL Profiler and check the generated queries, you can see that there is no difference between two types of queries in terms of performance. So, just your taste in code style.

Like others have suggested, it's more of a personal preference. I like the use of && as it's more readable and mimics the syntax of other mainstream languages.