LINQ: The care and feeding of LINQ operators (part 2–Any & All)

My last post was an intro to Any and All – with this post I will weave Where into the mix. I’ll warn that some of this may seem personal preference, but this post is really about what constitutes effective and idiomatic LINQ. IMHO, without having some of these ideas about good LINQ and bad LINQ is a bit like a craftsman that doesn’t care about using a chisel when a screwdriver is appropriate.

Filtered input feeding a LINQ operator

I wish I had a nickel for every time I’ve seen:

// ugh! don't do this:
items.Where(x => pred(x)).Any())

I like to think of LINQ as a pipeline that includes a Where like this as “filtered input feeding a LINQ operator.” If the no-argument LINQ operator fed by the Where also has an an overload with a single-argument predicate, then you can always use that rather than the more complex Where…Op, like so:

// do this!
items.Any(x => pred(x))

Besides being less code, it’s closer to the predicate-logic (there exists an x such that predicate) kind of language, it’s more declarative and it has a shorter pipeline chain. I think there are plenty of reasons to claim this is idiomatic & effective.

The operator doesn’t have to be just Any that is fed by Where – all of the LINQ operators that have predicate and no-predicate overloads work here: First, Last, Single, Count and of course Any.

Don’t do this: Do this:
items.Where(x=>p(x).Any() items.Any(x=>p(x))
items.Where(x=>p(x).First() items.First(x=>p(x))
items.Where(x=>p(x).Count() items.Count(x=>p(x))
items.Where(x=>p(x).Last() items.Last(x=>p(x))
items.Where(x=>p(x).Single() items.Single(x=>p(x))

…and of course their “OrDefault” overloads where they exist.

Where Feeding a LINQ Operator That Has A Predicate

Similar to Where feeding a non-predicated operator, Where feeding a predicated operator is another case where I generally like to get rid of the Where and roll its predicate into the other operator – we’ll cover rolling Where into All separately because All is special.

Illustrating with Where…Any:

items.Where(x => p1(x)).Any(x => p2(x))

Rolling Where…Any into just Any:

items.Any(x => p1(x) && p2(x))

..but of course it works for First, Last, Count and Single. It doesn’t work for SkipWhile or TakeWhile because they will end up yielding values from  the filtered sequence. Since Any and All are related, it may come as a surprise that in regard to combining Where with All, that…

All is special!

But why is All special? Consider this:

items.Where(i => i != null).All(x => x.IsFoo)

What happens if all of the items are null? The above expression will be vacuously true. However, if we combined it like this:

// NOT EQUIVALENT! Don't do this!
items.All(x => x != null && x.IsFoo)

If you have an inkling about what the right thing to do is, hold off just a second. We will derive an equivalent expression using the relationship between Any and All from the previous post and the above to arrive at an elegant solution that is correct for all predicates. We can do this by adding a not to the entire expression, changing All to Any and negating All’s predicate, like so:

General form of Where feeding All

items.Where(x => p1(x)).All(x => p2(x))

Let’s first convert this to an equivalent expression with Any instead of All :

!items.Where(x => p1(x)).Any(x => !p2(x))

From the previous section of this post, we know how to combine Where and Any; we delete Where and modify Any‘s predicate, combining the original Where predicate with Any‘s predicate by ANDing them like so:

!items.Any(x => p1(x) && !p2(x))

Now we’re ready to convert Any back to All – we do so exactly the same way we converted All to Any in our first step – we’ll also apply De Morgan’s Laws for negating Any’s predicate. In applying that we end up with the replacement rule we sat out to write (and now we know why All is special):

 // yay! We have derived our replacement rule for Where..All
items.All(x => !p1(x) || p2(x))

So let’s go back to example that threw things off:

// the original
items.Where(x => x != null).All(x => x.IsFoo)

// transform for Where..All
items.All(x => x == null || x.IsFoo)

If items is empty – this is vacuously true. If items contains only nulls, this returns true. In fact, nulls won’t cause this construct to return false – it’s the nonnull values – if any of them is not an IsFoo, then this construct will return false. Woot! It checks out!

Conclusion

With the exception of the positional predicates that Where supports, Where can always be rolled into Single, First, Last, Any, All, Count and the OrDefault overloads for first three operators (no love for TakeWhile and SkipWhile, they operate on and provide items from the filtered output of Where.) While I’m not dogmatic about this, it’s good to have this under your belt if you want to write the simplest LINQ possible.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s