Anti-patterns

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

Anti-pattern

Do this instead

✕ Callback pyramids

✓ Use async / await; flatten error handling into try/catch.

✕ Loose equality and implicit coercion

✓ Use === and convert types explicitly (Number(x), String(x)).

✕ Blocking the event loop with CPU work

✓ Move heavy computation to worker threads or a separate service.

✕ Extending built-in prototypes

✓ Write utility functions or classes; monkey-patching Array.prototype breaks other code.

✕ Shared mutable state across modules

✓ Prefer pure functions and explicit state containers.

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).