The fastest way to ship a bug is to ask a collection the wrong question.\n\nI see this constantly in real systems: someone wants to know whether a user has any active subscription, whether an order has any refundable line items, whether a cart has any out-of-stock products, whether a feature flag set contains any enabled toggles… and the code ends up doing extra work (or worse, returning the wrong answer) because the query is framed as counting, filtering, or materializing.\n\nAny is the LINQ quantifier I reach for when the business question is truly binary: “does at least one element match?” It reads like English, it stops as soon as it can, and when you’re querying remote providers (like a database), it often becomes the cheapest possible query.\n\nWhat follows is how I think about Any day-to-day: the two overloads, short-circuiting behavior, how it behaves with IEnumerable vs IQueryable, what it translates to in SQL, the mistakes I see during code reviews, and the patterns I recommend when you want correctness and predictable performance.\n\n## What Any Really Means (and the trap people fall into)\nAny answers exactly one question:\n\n- Predicate form: “Does this sequence contain at least one element that matches this condition?”\n- Parameterless form: “Does this sequence contain at least one element?”\n\nThat’s it. It does not mean “are all elements valid?” (that’s All). It does not mean “is there a specific element present?” (that can be Contains, or Any(x => x == value)).\n\nA surprisingly common misunderstanding is the idea that Any becomes false when a non-matching element exists. That would be a bizarre operator: almost every non-trivial collection contains at least one non-matching element for most predicates.\n\nHere’s the mental model I use:\n\n- Any(predicate) returns true the moment it finds the first match.\n- It returns false only if it reaches the end with zero matches.\n\nAnalogy: imagine you’re scanning a guest list at the door. If you spot one VIP, you can answer “yes, a VIP is present” immediately. You don’t need to keep scanning.\n\nOne more framing trick I use in code reviews: translate the line into plain English and see if the logic still holds.\n\n- orders.Any(o => o.Total > 0) → “Do we have at least one order with total greater than 0?”\n- orders.Where(o => o.Total > 0).Any() → same question, but phrased in a longer way\n- orders.Count(o => o.Total > 0) > 0 → same question, but now you’re asking for a count you don’t actually need\n\nIf the requirement is binary, pick the binary operator. That’s not micro-optimization; it’s aligning code shape with the business question.\n\n### Empty sequences and vacuous truth\nTwo edge cases matter a lot in production:\n\n- Any() on an empty sequence returns false.\n- Any(predicate) on an empty sequence also returns false.\n\nThat’s different from All(predicate), where an empty sequence returns true (the “vacuous truth” rule). I call this out because I’ve watched teams accidentally grant access or mark validation as passing because they swapped Any and All without thinking about empties.\n\nIf you remember only one rule about empties, make it this: Any is pessimistic on empties; All is optimistic.\n\n### A quick truth table I keep in my head\nGiven a predicate p:\n\n- Empty sequence: Any(p) == false, All(p) == true\n- Sequence with no matches: Any(p) == false, All(p) == false\n- Sequence with some matches: Any(p) == true, All(p) == false\n- Sequence where every element matches: Any(p) == true, All(p) == true\n\nThis table is why confusing Any and All is so dangerous: the “some matches” case is where real data usually lives.\n\n## The Two Overloads I Use Most (and why)\nAny is overloaded in two main forms:\n\n1) Any(IEnumerable source)\n- “Is there at least one element?”\n\n2) Any(IEnumerable source, Func predicate)\n- “Is there at least one element matching a condition?”\n\nI use the parameterless overload primarily as a readability tool and a performance hint:\n\n- Guard clauses: don’t proceed if a list is empty.\n- Fast checks: don’t allocate or count; just confirm existence.\n\nI use the predicate overload to avoid building intermediate sequences:\n\n- Instead of Where(...).Any() I usually write Any(...) directly.\n- It communicates intent: you are not trying to “get” anything, only to know whether it exists.\n\nThere’s also a subtle cognitive benefit: Any(predicate) forces you to write the condition at the point where you ask the yes/no question. I’ve found that reduces “half-finished refactors” where a Where was added earlier for some now-deleted purpose but still sits there, filtering data for no reason.\n\n### Runnable example: basic existence checks\nC# (runnable):\n\n using System;\n using System.Linq;\n using System.Collections.Generic;\n\n public static class Program\n {\n public static void Main()\n {\n int[] orderIds = { 34, 56, 77, 88, 99, 10, 23, 46 };\n string[] regions = { \"na\", \"eu\", \"apac\", \"latam\" };\n char[] flags = { ‘c‘, ‘c‘, ‘A‘, ‘E‘, ‘u‘ };\n\n bool hasOrder10 = orderIds.Any(id => id == 10);\n bool hasEuRegion = regions.Any(r => r == \"eu\");\n bool hasLowercaseC = flags.Any(ch => ch == ‘c‘);\n\n Console.WriteLine($\"Has orderId 10? {hasOrder10}\");\n Console.WriteLine($\"Has region ‘eu‘? {hasEuRegion}\");\n Console.WriteLine($\"Has flag ‘c‘? {hasLowercaseC}\");\n }\n }\n\nIf you run that, you’ll see True for all three checks.\n\n### Runnable example: empty list check\nC# (runnable):\n\n using System;\n using System.Linq;\n using System.Collections.Generic;\n\n public sealed class Employee\n {\n public required string Name { get; init; }\n }\n\n public static class Program\n {\n public static void Main()\n {\n List employees = new();\n\n bool hasAnyEmployees = employees.Any();\n Console.WriteLine($\"Has any employees? {hasAnyEmployees}\");\n\n employees.Add(new Employee { Name = \"Riya\" });\n\n hasAnyEmployees = employees.Any();\n Console.WriteLine($\"Has any employees after add? {hasAnyEmployees}\");\n }\n }\n\n## Short-Circuiting, Deferred Execution, and Side Effects\nIn LINQ, most query operators are lazy: they don’t do anything until you enumerate. Any is different in an important way:\n\n- Any forces enumeration immediately (because it must decide true/false).\n- It enumerates as little as needed.\n\nThat second bullet is the key performance and correctness property:\n\n- On IEnumerable, it pulls items one by one until it finds a match.\n- On IQueryable, it usually becomes a provider query that returns as soon as the provider can prove existence.\n\nA detail I find worth emphasizing: short-circuiting is not just about speed. It’s about behavior. The moment you accept short-circuiting, you should treat Any (and friends like All) as control-flow operators, not just “collection helpers.”\n\n### Why I avoid side effects inside Any\nBecause Any can stop early, side effects inside the predicate are a footgun. If you log, mutate, or increment counters inside the predicate, the behavior depends on where the first match occurs.\n\nBad pattern (don’t do this):\n\n bool hasSuspicious = events.Any(e =>\n {\n auditLog.Add($\"Scanned {e.Id}\");\n return e.Type == \"suspicious\";\n });\n\nIf the first item is suspicious, you only log one scan. If the suspicious item is last, you log everything. That inconsistency becomes a debugging nightmare.\n\nWhat I do instead:\n\n- Keep predicates pure: no mutation, no I/O.\n- If you need audit trails, enumerate explicitly and log deterministically.\n\nIf I really want “scan everything and then answer existence,” I don’t use Any. I’ll do a foreach and track a flag, or I’ll materialize and then run Any on the materialized list. The point is: be honest about what you need.\n\n### Any and multiple enumeration\nAny consumes the enumerator. If your source is a one-shot sequence (common with streaming APIs), calling Any and then enumerating again may drop data.\n\nIf you have a potentially one-time enumerable, consider materializing once:\n\n- var items = source.ToList();\n- Then do checks: items.Any(...).\n\nI don’t materialize by default, but I do it when the source is:\n\n- a network stream,\n- a generator that can’t be re-run,\n- or an enumerable with expensive iteration.\n\nThere’s a related “gotcha” I see with deferred queries over mutable collections. If you build a query once and then mutate the underlying list before calling Any, you’re not checking what you think you’re checking. I treat this as a correctness issue: either check immediately, or snapshot the data you intend to reason about.\n\n### How far does Any() enumerate, really?\nFor IEnumerable sources, Any() usually only needs a single MoveNext() call:\n\n- If the sequence has at least one element, Any() can return true after seeing the first element.\n- If it’s empty, it has to attempt that first move and will return false.\n\nSome sequences can answer “do you have any items?” without pulling elements at all (for example, collections that expose a Count property). Internally, the LINQ implementation has fast paths for common collection types. I don’t write code to depend on those fast paths, but it’s one reason Any() is often a better expression of intent than forcing enumeration via Count().\n\n## Any with IQueryable: SQL Translation and Provider Surprises\nWhen your source is IQueryable (Entity Framework Core, LINQ to SQL, some document DB providers), Any is often the best possible existence check.\n\nThe typical translation looks like:\n\n- Any(predicate) becomes a query that checks for existence (often EXISTS) with a filter.\n- Any() becomes an existence check without a filter.\n\nWhy I like this:\n\n- It avoids transferring rows you don’t need.\n- It avoids counting when you only need yes/no.\n- It aligns with how databases answer existence efficiently.\n\nIf you only need “is there at least one?”, Any is a strong default because it gives the provider freedom to stop early. A database can stop scanning as soon as it finds the first qualifying row; it does not have to count all rows.\n\n### The big rule: keep Any server-evaluable\nIf your predicate can’t translate to the underlying provider, you might accidentally force client-side evaluation or get a runtime exception (behavior varies by provider and settings).\n\nSafe, typically translatable:\n\n- comparisons (==, <, >) on mapped fields\n- boolean logic\n- null checks\n- simple string operations supported by your provider\n- navigation property checks that the provider understands\n\nRisky:\n\n- calling arbitrary .NET methods in the predicate\n- using complex local functions\n- regex matching (often unsupported or translated in surprising ways)\n- using local collections in a way that expands into huge IN (...) lists\n\nMy practical workflow is: if I’m in an IQueryable context, I treat the predicate like a “query language,” not like normal in-memory C#. When I need real C# logic, I’ll pull data into memory intentionally (with a clear boundary) and then run Any (and other LINQ-to-Objects operators) on the in-memory results.\n\n### Pattern I recommend for authorization checks\nReal-world scenario: “Does this user have any permission that allows publishing?”\n\nWith a database-backed model, I want the DB to answer it:\n\n // Pseudocode shape; adjust to your actual DbContext and entities\n bool canPublish = db.UserPermissions\n .Where(p => p.UserId == userId)\n .Any(p => p.Permission == \"PublishArticle\" && p.IsRevoked == false);\n\nThe key is that Any returns a boolean directly, which makes guard clauses clean:\n\n if (!canPublish)\n return Forbid();\n\nIn practice, I often collapse the Where and predicate into one Any, because it’s even more direct:\n\n bool canPublish = db.UserPermissions\n .Any(p => p.UserId == userId\n && p.Permission == \"PublishArticle\"\n && !p.IsRevoked);\n\nThis is one of those tiny refactors that pays off in long-lived systems: fewer query operators, less mental stack, and fewer places to accidentally change behavior during future edits.\n\n### Any and async\nWith EF Core, you typically use AnyAsync() to avoid blocking threads in ASP.NET:\n\n- await query.AnyAsync(cancellationToken)\n\nI treat AnyAsync as the default choice in request/response codepaths. Sync Any is fine in console apps or when you already have data in memory.\n\nOne nuance: “async” does not magically make the query faster—it just uses threads more responsibly. But in services, that distinction is huge. I’ve seen systems fall over not because the database was slow, but because synchronous queries blocked the thread pool under load.\n\n### How I think about SQL shapes: EXISTS vs COUNT()\nI don’t obsess over the exact SQL text, but I do care about the shape of what’s being asked.\n\n- Any maps naturally to EXISTS, which is optimized for “stop when found.”\n- Count() > 0 maps naturally to counting, which may require scanning more data than necessary.\n\nEven when a provider is clever enough to optimize Count() > 0 into an existence check, I still prefer Any() in code because it documents intent at the call site. The next person reading the code shouldn’t need to know provider internals to understand your performance posture.\n\n## Patterns I Reach For in Real Code\nHere are a few patterns I keep repeating because they’re readable, safe, and hard to break.\n\n### 1) Guard clauses for invalid input\nIf you accept a list of IDs to process, fail early when it’s empty.\n\n if (!requestedOrderIds.Any())\n throw new ArgumentException(\"At least one orderId is required.\", nameof(requestedOrderIds));\n\nThis reads like the business rule.\n\nIf null is possible (and meaningful), I make the behavior explicit rather than hoping it never happens:\n\n if (requestedOrderIds is null || requestedOrderIds.Count == 0)\n throw new ArgumentException(\"At least one orderId is required.\", nameof(requestedOrderIds));\n\nI avoid requestedOrderIds?.Any() == true in most domain code because it quietly treats null as false. That may be correct sometimes, but it’s also a great way to hide a bug.\n\n### 2) “Any invalid?” beats “All valid?” in validation pipelines\nIf you want to reject when anything is invalid, I often prefer Any(invalid) over All(valid) because the invalid predicate is closer to the failure behavior.\n\nExample: “Reject if any item has a negative quantity.”\n\n bool hasInvalidQuantity = lineItems.Any(li => li.Quantity < 0);\n if (hasInvalidQuantity)\n return ValidationError(\"Quantity cannot be negative.\");\n\nThis is also friendly for error reporting: once you know “some invalid exists,” you can follow up by locating the first invalid item using First or FirstOrDefault in a separate step.\n\nA pattern I use a lot looks like this:\n\n var firstInvalid = lineItems.FirstOrDefault(li => li.Quantity < 0);\n if (firstInvalid is not null)\n return ValidationError($\"Invalid quantity for SKU {firstInvalid.Sku}.\");\n\nIt’s the same short-circuit behavior as Any, but now I get the evidence that explains the decision.\n\n### 3) Existence checks in hierarchical data\nScenario: “Does any order contain a backordered line?”\n\nC# (runnable):\n\n using System;\n using System.Linq;\n using System.Collections.Generic;\n\n public sealed class Order\n {\n public required string OrderNumber { get; init; }\n public required List Lines { get; init; }\n }\n\n public sealed class OrderLine\n {\n public required string Sku { get; init; }\n public required bool IsBackordered { get; init; }\n }\n\n public static class Program\n {\n public static void Main()\n {\n var orders = new List\n {\n new Order\n {\n OrderNumber = \"SO-10021\",\n Lines = new List\n {\n new OrderLine { Sku = \"KB-104\", IsBackordered = false },\n new OrderLine { Sku = \"MS-220\", IsBackordered = false },\n }\n },\n new Order\n {\n OrderNumber = \"SO-10022\",\n Lines = new List\n {\n new OrderLine { Sku = \"HD-002\", IsBackordered = true },\n }\n }\n };\n\n bool anyBackorders = orders.Any(o => o.Lines.Any(l => l.IsBackordered));\n Console.WriteLine($\"Any backorders? {anyBackorders}\");\n }\n }\n\nNested Any is one of the cleanest ways to express “exists in a hierarchy.”\n\nOne tip: when nested predicates get complicated, I sometimes name the inner predicate with a local function (for LINQ-to-Objects only) to keep readability high. For IQueryable, I avoid local functions unless I’m building expression trees intentionally.\n\n### 4) Feature flags and configuration sanity checks\nIf you load configuration into a dictionary or list, Any is a quick sanity test:\n\n bool hasAnyEnabledFlags = flags.Any(f => f.Enabled);\n\nIf you later need to enumerate enabled flags, do that separately. I keep the existence check separate from the selection step to make intent obvious.\n\nA pattern I like in config-heavy code is:\n\n- Use Any to choose a branch (“should we enable the feature pipeline at all?”).\n- Use Where/Select to build the list only in the branch where it’s needed.\n\nThat keeps work proportional to the decision.\n\n## Performance Notes: What Any Buys You (and when it doesn’t)\nI care about performance, but not in a “count microseconds at all costs” way. I care about avoiding accidental big work.\n\n### Any vs Count() > 0\nWhen I see Count() > 0, I nearly always replace it with Any().\n\nWhy:\n\n- Count() may iterate the entire sequence.\n- Any() can stop at the first element.\n\nThere are a few exceptions:\n\n- If you already need the count for other logic, use the count once.\n- Some collections have an O(1) Count property; but LINQ Count() doesn’t always use it, depending on the source type and overload.\n\nMy practical rule: if the question is boolean, use the boolean operator.\n\n### Any(predicate) vs Where(predicate).Any()\nThese are functionally equivalent for most IEnumerable sources, and both can short-circuit.\n\nI still prefer Any(predicate) because:\n\n- It’s one operator expressing one idea.\n- It avoids building a pipeline that suggests you might want the filtered sequence.\n\nThere’s also a maintenance reason: it’s common for a developer to insert additional Wheres or projections between Where and Any during refactors. With Any(predicate), you’re less likely to accidentally end up with a more complex query pipeline than you intended.\n\n### Any(x => x == value) vs Contains(value)\nIf you’re checking equality membership, Contains(value) communicates that intent better.\n\n- Contains reads like “set membership.”\n- Any reads like “existence of a match.”\n\nThey can be identical in runtime behavior for many sources, but readability matters. And for some sources, Contains may be optimized in ways that a generic Any predicate is not.\n\n### Watch out for repeated membership checks\nIf you do many membership checks against the same in-memory collection, the data structure matters more than LINQ.\n\nExample: you validate 10,000 events against a list of blocked customer IDs. If the blocked IDs are in a List, each Contains is a linear scan. Convert once:\n\n- var blocked = blockedCustomerIds.ToHashSet();\n- blocked.Contains(customerId) becomes much faster and more stable as the list grows.\n\nI treat this as one of the easiest wins in typical services: you pay a small one-time cost to build a HashSet, then you get predictable lookup time.\n\n### Typical latency ranges I actually see\nWhen you’re working in-memory:\n\n- Any() on a non-empty list is effectively “near-zero” from a human perspective.\n- Any(predicate) is proportional to how early you match.\n\nWhen you’re querying a database:\n\n- AnyAsync() often returns in the “single-digit milliseconds to a few tens of milliseconds” range in healthy systems, depending on indexes, network distance, and contention.\n\nThe main point: Any keeps you from dragging full rows over the wire when you only needed a yes/no.\n\n## Common Mistakes I Catch in Code Reviews\nThese are patterns I actively look for because they cause incorrect results or unnecessary work.\n\n### Mistake 1: confusing Any with All\nI see this in permissions and validation.\n\n- You want “must have at least one permission,” you wrote All and accidentally require every permission.\n- You want “no invalid entries,” you wrote Any(valid) and accidentally accept partially-valid inputs.\n\nI fix this by rewriting the requirement in plain English and mapping it:\n\n- “At least one matches” → Any\n- “Every element matches” → All\n\n### Mistake 2: calling Any on a null source\nLINQ operators throw ArgumentNullException when source is null. That’s good: it surfaces a bug early.\n\nIf null is a legitimate state in your domain, decide the behavior explicitly:\n\n- If null means “no items,” coalesce: (items ?? Enumerable.Empty()).Any()\n- If null is a bug, let it throw and fix the call\n\nI’ll add one more nuance: in nullable-reference-type codebases, I strongly prefer making nullability reflect reality. If a sequence can be absent, model it as nullable and handle it intentionally. If it must exist, keep it non-nullable and let the runtime throw loudly when someone violates the contract.\n\n### Mistake 3: using Any when you actually need the element\nI sometimes see code that does Any and then repeats the same predicate to fetch the element:\n\n- if (items.Any(p)) { var x = items.First(p); ... }\n\nThat enumerates twice for IEnumerable sources. For lists it might be fine; for streaming sources it’s broken; for expensive sources it’s wasteful.\n\nIf you need the element, just get it once:\n\n- var x = items.FirstOrDefault(p); if (x is not null) ...\n\nOr if “not found” should be exceptional, use First(p) and let it throw. The important part is: Any is the right tool only when the output you need is boolean.\n\n### Mistake 4: thinking Any() means “not null”\nThis sounds obvious, but it still shows up: someone writes if (items.Any()) intending it as a null check. That works only if items is guaranteed not null.\n\nIf you truly need “exists and non-empty,” express it:\n\n- if (items is { Count: > 0 }) for collections\n- if (items?.Any() == true) if null should be treated as empty (rarely my default)\n\nI try not to be clever here. “Null vs empty” is a domain decision; Any shouldn’t quietly make that decision for you.\n\n## Choosing Between Any, All, Contains, First, and Count\nWhen teams struggle with Any, it’s usually because the real confusion is upstream: they haven’t named the question precisely. Here’s the cheat sheet I use to choose quickly:\n\n- “Do we have at least one element?” → Any()\n- “Do we have at least one element matching X?” → Any(x => X)\n- “Do all elements match X?” → All(x => X)\n- “Do we have this exact value?” → Contains(value)\n- “Give me the first element matching X (or throw).” → First(x => X)\n- “Give me the first element matching X (or default).” → FirstOrDefault(x => X)\n- “How many elements match X?” → Count(x => X)\n\nNotice what’s missing: “Is the sequence valid?” That’s not one operator. That’s a decision, and you have to define validity. Quantifiers are tools; they don’t replace requirements.\n\n## Any in Query Composition: Keeping Intent Clear\nI like Any most when it sits at a decision boundary: an if, a guard clause, a returned boolean, or a rule evaluation. That’s where binary answers belong.\n\n### Prefer returning booleans directly\nIf a helper method exists just to answer yes/no, I structure it as a boolean-returning function that uses Any internally:\n\n- bool HasRefundableLineItems(Order order)\n- Task UserHasActiveSubscriptionAsync(Guid userId)\n\nThis keeps business rules reusable and testable. It also discourages callers from materializing whole object graphs just to answer existence questions.\n\n### Be careful with “boolean helpers” that hide extra work\nA pitfall: a method named like an existence check (HasX) that does a ToList() or loads lots of related data. Any is often the fix: you can usually rewrite the method so it asks the store for existence instead of asking for data.\n\nAs a code review rule, if I see a HasSomething() method returning bool, I immediately look for hidden allocations, hidden Includes, or hidden “fetch all then check.”\n\n## Any with Relationships (and why it’s so expressive)\nOne of the reasons I love Any is that it matches how I think about relationships:\n\n- A user has many subscriptions\n- An order has many lines\n- A product has many reviews\n\nMost of the time, the question is not “how many” but “does there exist at least one that satisfies a rule?”\n\nHere are a few shapes I see constantly:\n\n- users.Any(u => u.Subscriptions.Any(s => s.IsActive))\n- orders.Any(o => o.Lines.Any(l => l.IsRefundable && l.Amount > 0))\n- products.Any(p => p.Reviews.Any(r => r.Rating <= 2))\n\nThis reads almost exactly like the product requirement. That’s what you want.\n\nIf you’re in IQueryable, these shapes often translate into efficient SQL with EXISTS subqueries. If you’re in-memory, they short-circuit naturally and stop as soon as they find a match.\n\n## Any and Testing: Verifying the Edge Cases You’ll Forget\nIf your code uses Any in validation, authorization, or billing flows, the unit tests I want to see are not just “happy path.” They are the edge cases that quantifiers make easy to misread:\n\n- Empty sequence returns false\n- Exactly one matching item returns true\n- Multiple items where the first matches (short-circuit doesn’t break anything)\n- Multiple items where only the last matches (still true)\n- No items match (false)\n\nI’m not testing LINQ itself; I’m testing that the predicate reflects the business requirement. These tests catch the classic bug where someone accidentally writes the negation wrong or uses All when they meant Any.\n\nA trick I use: write a test where the first element is a “poison pill” that would throw if evaluated. If the logic truly short-circuits, it won’t evaluate it. I only do this for LINQ-to-Objects code (never for providers), and only when short-circuit behavior is critical to correctness.\n\n## When Not* to Use Any\nEven though I’m clearly pro-Any, I don’t use it everywhere. Here are the cases where it’s usually the wrong tool:\n\n- You need the element itself (use First, Single, or their OrDefault variants).\n- You need the count (use Count, but only once).\n- You’re about to repeat the same expensive predicate twice (get the element once instead).\n- Your predicate has side effects (don’t do side effects in LINQ predicates).\n- Your source is expensive or one-shot and you need to use it again (materialize intentionally).\n\nI’m not trying to ban Any misuse with style rules. I’m trying to protect a very clean operator from being used as a vague “LINQ hammer.”\n\n## Expansion Strategy\nAdd new sections or deepen existing ones with:\n- Deeper code examples: More complete, real-world implementations\n- Edge cases: What breaks and how to handle it\n- Practical scenarios: When to use vs when NOT to use\n- Performance considerations: Before/after comparisons (use ranges, not exact numbers)\n- Common pitfalls: Mistakes developers make and how to avoid them\n- Alternative approaches: Different ways to solve the same problem\n\n## If Relevant to Topic\n- Modern tooling and AI-assisted workflows (for infrastructure/framework topics)\n- Comparison tables for Traditional vs Modern approaches\n- Production considerations: deployment, monitoring, scaling\n\nKeep existing structure. Add new H2 sections naturally. Use first-person voice.\n\n### A practical closing thought\nIf you want one habit that improves both correctness and performance: whenever you’re about to write a query, say the question out loud. If the answer is “yes or no,” start with Any. It’s one of those small choices that compounds across a codebase—fewer wasted queries, fewer accidental full scans, fewer misread validations, and fewer bugs shipped because a collection was asked the wrong question.\n
