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

✕ Owning raw pointers with new/delete

✓ Use std::make_unique / std::make_shared; leaks and double frees disappear.

✕ using namespace std; in headers

✓ Qualify names (std::string) or put using-declarations inside .cpp files only.

✕ Macros for constants and functions

✓ Use constexpr variables, inline functions and templates; they respect scope and types.

✕ Relying on undefined behaviour

✓ Signed overflow, out-of-bounds access and dangling references “work” until they don't. Use sanitizers and .at() while debugging.

✕ Catching exceptions by value

✓ Catch by const reference (catch (const std::exception& e)) to avoid slicing.

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