Introduction

In LINQ, !Any(predicate) and All(x => !predicate(x)) are logically equivalent for finite sequences, but they are not always equally readable. Choosing the clearer form matters in real code, especially when predicates are already negative. Understanding empty-sequence behavior also prevents subtle validation bugs.

Core Sections

Logical relationship between the two forms

For a predicate p, these are equivalent:

• !source.Any(p)
• source.All(x => !p(x))

Both mean “there is no element that satisfies p.”

Example:

1var nums = new[] { 2, 4, 6 };
2
3bool noOddA = !nums.Any(n => n % 2 != 0);
4bool noOddB = nums.All(n => n % 2 == 0);
5
6Console.WriteLine(noOddA == noOddB); // true

Readability guidelines

Even though equivalent, one form can be easier to understand:

• use positive All when domain statement is naturally universal
• use !Any when domain statement is naturally existential absence

Example of clearer expression:

• orders.All(o => o.IsApproved) is often clearer than !orders.Any(o => !o.IsApproved)

Prefer fewer negations in code paths that are already complex.

Empty sequence behavior

Important semantics:

• Any on empty sequence returns false
• All on empty sequence returns true

So for empty sequences, both forms still match:

• !Any(p) becomes true
• All(not p) also true

This is mathematically consistent but can surprise developers expecting explicit non-empty validation.

If non-empty requirement exists, combine checks explicitly.

bool allApprovedAndNotEmpty = orders.Any() && orders.All(o => o.IsApproved);

Performance characteristics

Both methods short-circuit:

• Any stops at first matching item
• All stops at first non-matching item

In practice performance is similar for equivalent predicates. Choose based on clarity, not micro-optimization assumptions.

Avoid double-negative predicates

Code gets hard to read when domain condition is already negated.

Hard to parse:

!users.Any(u => !u.IsActive)

Clearer:

users.All(u => u.IsActive)

Express business rule directly whenever possible.

Complex predicates and helper methods

If predicate is long, extract helper methods rather than nesting negations inline.

bool IsCompliant(Order o) => o.IsApproved && o.Amount > 0 && o.Currency == "USD";

bool allCompliant = orders.All(IsCompliant);

This improves testability and reduces cognitive load in reviews.

Practical testing strategy

For code that uses either form, include tests for:

• empty sequence
• one matching element
• one non-matching element
• mixed collection

These cases catch most logic misunderstandings quickly.

Query provider considerations

When using LINQ with query providers such as Entity Framework, translation of Any and All can differ in generated SQL shape. Semantics remain equivalent, but execution plans may vary based on indexes and predicate complexity. If performance matters for large datasets, inspect generated SQL and actual query plans rather than assuming identical runtime cost.

Team readability conventions

Set one convention in your codebase and apply it consistently. For many teams, positive All expressions are easier to review than nested negations. Whatever convention you choose, document it in style guidelines so code reviews focus on business logic instead of repeated syntax debates. This consistency also improves static analysis rules and auto-review tooling, because patterns become predictable and easy to detect. It also reduces reviewer fatigue in large PRs.

Establish a team style note for predicate polarity so reviewers can quickly spot logic inversion risks in Any, All, and ! combinations.

Common Pitfalls

• Assuming All returns false for empty sequences.
• Writing nested negations that hide business intent.
• Using one form for style preference without considering readability.
• Forgetting to add non-empty check when domain requires at least one element.
• Refactoring predicates without preserving logical equivalence.

Summary

• !Any(p) and All(not p) are equivalent in LINQ for finite sequences.
• Prefer the expression that states business intent most clearly.
• Remember both forms return true on empty sequences.
• Add explicit non-empty checks where required by domain rules.
• Keep complex predicates readable with helper methods and targeted tests.