Add Post Draft

Author: Xen0byte

content/posts/2025-XX-XX-stop-using-var/draft.txt

@@ -0,0 +1,194 @@
+-- it's a calamitous atrocity --
+
+If `clients` is an **enumeration (`IEnumerable<T>`)** rather than a **concrete collection (`List<T>`, `T[]`, etc.)**, then every time you iterate over `clients` (e.g. in a `foreach`, `.ToList()`, `.Count()`, etc.), the underlying sequence will be re-evaluated.
+
+### What this means in practice:
+
+* **If `GetClients()` returns a query** (like an EF Core LINQ query, or something built on `yield return`):
+
+  * Each enumeration re-runs the logic, potentially hitting the database or recomputing values.
+  * Side effects (logging, network calls, DB queries) happen every time you iterate.
+  * Performance can degrade unexpectedly.
+* **If it returns a materialized collection** (`List<T>`, `Array`, `HashSet<T>`, etc.):
+
+  * No problem. Multiple iterations are just reusing the already-fetched in-memory data.
+
+### Example
+
+```csharp
+var clients = context.Clients.Where(c => c.IsActive); // IQueryable/IEnumerable
+foreach (var c in clients) { ... } // Executes query
+foreach (var c in clients) { ... } // Executes query again!
+```
+
+vs.
+
+```csharp
+var clients = await context.Clients.Where(c => c.IsActive).ToListAsync(); 
+foreach (var c in clients) { ... } // Uses same in-memory list
+foreach (var c in clients) { ... } // Still in-memory, no extra DB call
+```
+
+### Rule of thumb
+
+If you’re not 100% sure whether the source is materialized, **force it with `.ToList()` or `.ToArray()`** when you assign:
+
+```csharp
+var clients = (await GetClients()).ToList();
+```
+
+👉 This guarantees that `clients` is a concrete collection, safe to reuse without surprises.
+
+---
+
+### 2. **Unintended numeric type**
+
+```csharp
+var total = 1 / 2; 
+```
+
+* Type: `int` (since both operands are `int`).
+* Problem: `total` becomes `0`, not `0.5`. If you thought it was `double`, you’ll silently get wrong results.
+* Fix:
+
+  ```csharp
+  double total = 1 / 2.0; // 0.5
+  ```
+
+---
+
+So in short:
+
+* With queries, `var` can hide that you’re holding a deferred-execution enumerable instead of actual data.
+* With arithmetic, `var` can lock you into an unintended (smaller or lossy) type.
+
+---
+Perfect 👍 — here’s a **Top 10 `var` Pitfalls in C# Cheat Sheet**, each with a quick code sample and what can go wrong.
+
+---
+
+## 🔟 Common Pitfalls with `var`
+
+### 1. **Deferred Execution (`IEnumerable` vs concrete collection)**
+
+```csharp
+var clients = db.Clients.Where(c => c.IsActive); // IQueryable<Client>
+foreach (var c in clients) { } // DB query executes
+foreach (var c in clients) { } // Executes again!
+```
+
+💥 Multiple queries when you thought it was cached.
+✅ Fix: `var clients = db.Clients.Where(...).ToList();`
+
+---
+
+### 2. **Anonymous Types Can’t Escape Scope**
+
+```csharp
+var client = new { Name = "Alice", Age = 30 }; 
+```
+
+💥 Can’t return this type from a method or store in a collection.
+✅ Use a real `Client` class.
+
+---
+
+### 3. **Async Return Confusion (`Task<T>` vs `T`)**
+
+```csharp
+var text = File.ReadAllTextAsync("file.txt"); // Task<string>
+Console.WriteLine(text.Length); // ❌ Not what you think
+```
+
+💥 Accidentally working with the `Task`, not the result.
+✅ `var text = await File.ReadAllTextAsync("file.txt");`
+
+---
+
+### 4. **Numeric Overflow / Wrong Type**
+
+```csharp
+var big = 100000 * 100000; // int
+Console.WriteLine(big); // ❌ Overflow
+```
+
+💥 Silent overflow since it’s `int`.
+✅ `long big = 100000L * 100000;`
+
+---
+
+### 5. **Integer Division Surprise**
+
+```csharp
+var ratio = 1 / 2; // int
+Console.WriteLine(ratio); // 0
+```
+
+💥 If you expected a `double`, you’re wrong.
+✅ `double ratio = 1 / 2.0;`
+
+---
+
+### 6. **Boxing and Performance Issues**
+
+```csharp
+var number = GetObject(); // object
+int value = (int)number;  // boxing/unboxing
+```
+
+💥 If you thought it was already `int`, perf and runtime errors appear.
+✅ Declare the concrete type.
+
+---
+
+### 7. **Nullable Value Types Hidden**
+
+```csharp
+var age = dbRow["Age"]; // object (nullable DB field)
+int x = (int)age;       // ❌ NullReferenceException
+```
+
+💥 You think it’s `int`, but it’s really `int?` or `object`.
+✅ Explicitly handle nullable types.
+
+---
+
+### 8. **Implicitly Wrong Collection Type**
+
+```csharp
+var clients = new[] { "Alice", "Bob" }; // string[]
+```
+
+💥 If you expected `List<string>`, you lose `List` methods.
+✅ Be explicit: `List<string> clients = new() { "Alice", "Bob" };`
+
+---
+
+### 9. **Dynamic APIs Returning `object`**
+
+```csharp
+var json = JsonSerializer.Deserialize<object>("{}");
+```
+
+💥 You think `json` is a dictionary, but it’s just `object`. Casting headaches follow.
+✅ Explicitly specify generic type: `Deserialize<Dictionary<string, object>>()`.
+
+---
+
+### 10. **Reduced Readability for Teams**
+
+```csharp
+var x = MethodThatReturnsSomething();
+```
+
+💥 Nobody knows what `x` is without hovering or jumping to definition. Maintenance pain.
+✅ Only use `var` when the type is obvious from the right-hand side.
+
+---
+
+## ✅ Rule of Thumb
+
+* Use `var` when the type is **clear and obvious** (e.g. `var client = new Client();`).
+* Avoid it when the type is **ambiguous, surprising, or critical to correctness** (async, queries, arithmetic).
+
+---