Anti-patterns

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

Anti-pattern

Do this instead

✕ Mutable default arguments (def f(x=[]))

✓ Use None and create the list inside: x = [] if x is None else x.

✕ Bare except:

✓ Catch specific exceptions; bare except also catches KeyboardInterrupt and SystemExit.

✕ from module import *

✓ Import names explicitly so readers and linters know where they come from.

✕ Membership tests on large lists in loops

✓ Use a set or dict for O(1) average lookups.

✕ Pure-Python loops over numeric arrays

✓ Vectorise with NumPy / pandas, which run the loop in C.

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