Code smell

What is a code smell?

A code smell is a surface-level pattern in source code that suggests a deeper design or maintainability problem. The term, popularized by Kent Beck and Martin Fowler, is deliberately about suspicion rather than certainty: a smell is not a bug, and code that smells can work perfectly today. What a smell reliably signals is that the code will be harder to change, easier to break, and more expensive to maintain than it should be. Classic examples include very long functions, duplicated logic, classes that know too much about each other, long parameter lists, and dead code that nobody dares delete.

How it shows up in real code

Smells cluster. A 400-line function usually keeps company with deeply nested conditionals, copy-pasted variants of itself, and a comment that says “do not touch”. A typical specimen:

function processOrder(order, user, flags, mode, legacy, skipEmail, ctx) { /* 300 lines */ }

Seven parameters, a boolean flag that switches behavior, and a body long enough to need its own table of contents. Each item is survivable alone; together they mean any change here is risky.

Why it matters in a code audit

Auditors treat smells as a map of where defects and slowdowns will come from. Duplicated logic means a future fix will be applied in one copy and missed in the others. A god class means every feature touches the same file and merge conflicts pile up. High cyclomatic complexity means branches nobody has ever tested. Smells are also the raw material of technical debt: individually cheap, collectively the reason “small” changes take weeks.

The useful audit output is not a shame list but a ranking: which smells sit in code that changes often and matters commercially, and which sit in a stable corner where they can be safely ignored. A catalog of the ones that show up in almost every codebase is in code smells every audit flags.

If you suspect your codebase has a few of these, a free code audit will tell you which ones actually matter.