Anti-patterns

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

Anti-pattern

Do this instead

✕ Concatenating user input into SQL

✓ Bind parameters with PDO prepared statements; SQL injection remains a top web vulnerability.

✕ Mixing HTML, SQL and logic in one file

✓ Separate layers: controller, service, template engine (Twig, Blade).

✕ Silencing errors with @

✓ Handle the failure explicitly and log it.

✕ global variables

✓ Inject dependencies through constructors or the framework container.

✕ Fat controllers

✓ Move business rules into services or domain objects; controllers translate HTTP only.

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