Anti-patterns

Solutions that look reasonable but cause problems. First the C#-specific traps, then the classics that apply everywhere.

Anti-pattern

Do this instead

✕ async void methods

✓ Return Task. Exceptions in async void cannot be awaited or caught; keep it for event handlers only.

✕ Blocking on async with .Result or .Wait()

✓ Await the task. Blocking can deadlock in contexts with a synchronization context and starves the thread pool.

✕ catch (Exception) { }

✓ Catch specific exceptions, log, and rethrow with throw; (not throw ex;) to keep the stack trace.

✕ Service locator everywhere

✓ Inject dependencies through constructors so they are visible and testable.

✕ Static mutable state

✓ Use DI-managed singletons; static state leaks between tests and requests.

One class knows and does too much. Split it by responsibility (SRP).

Tangled control flow with no structure. Refactor into small functions with clear inputs and outputs.

Using one familiar tool or pattern for every problem. Pick the simplest fit.

Optimising before measuring. Profile first, then fix the real bottleneck.

Duplicated logic drifts apart. Extract shared code once the duplication is real (rule of three).

Unexplained literals. Use named constants or enums.

Global state disguised as a pattern. Prefer dependency injection with a single-instance lifetime.

Dead or experimental code nobody dares to remove. Delete it; version control remembers.

Saved in this browser only. Part of From code to production (0/5).