Do code smells actually cause bugs? The research says yes - with important caveats
The empirical evidence is strong. Some smells correlate with defect density at statistically significant levels across multiple independent studies spanning three decades. Some do not. This page presents the data honestly, with the caveats the data requires.
| Smell | Defect association | Notes |
|---|---|---|
| God Class | Strong | Consistently the strongest single-smell defect association (Basili 1996, Palomba 2018) |
| Feature Envy | Strong | Coupling mechanism; Basili 1996 CBO link |
| Duplicate Code | Moderate | Shotgun Surgery and bug propagation |
| Long Method | Moderate | Cyclomatic-complexity correlation |
| Shotgun Surgery | Moderate | Change-proneness primary mechanism (Khomh 2012) |
| Inappropriate Intimacy | Moderate | Coupling; concurrent mutation risk |
| Parallel Inheritance | Moderate | Extension-point brittleness |
| Data Clumps | Weak | Validation fragmentation |
| Primitive Obsession | Weak | Type-safety absence; input validation gaps |
| Speculative Generality | Weak | Dead abstraction confusion |
| Data Class | Negligible | Scattered logic in callers, not in the class |
| Comments (apology) | Negligible | Signal, not cause; marks other smells |
Qualitative synthesis of the empirical literature (Basili 1996, Khomh 2012, Bavota 2015, Palomba 2018). The consistent finding across these studies is an ordinal one: coupling-heavy smells (God Class, Feature Envy) carry the strongest defect association, data and comment smells the weakest. We do not report a single pooled correlation coefficient, because no meta-analysis we can verify reports one per smell.
Tufano, Palomba, Bavota, Oliveto, Di Penta, De Lucia, and Poshyvanyk's “When and Why Your Code Starts to Smell Bad” (ICSE 2015) is the canonical large-scale study of how smells are introduced. The authors mined more than 500,000 commits across 200 open-source projects (Apache, Eclipse, Android) and manually analysed over 9,000 smell-introducing commits. The findings mostly contradict common wisdom:
- Most smells are introduced when a file is first created, not gradually accreted over its lifetime. When a clean file does degrade later, it tends to degrade sharply rather than drifting slowly.
- Smells are introduced overwhelmingly during enhancement and new-feature work, and disproportionately in the last month before a release. The deadline-pressure effect is real, but it shows up at release crunch rather than in routine maintenance.
- The developers who introduce most smells are the experienced file owners, not newcomers. This most likely reflects that senior developers take on the largest and most complex changes.
- Smells are sticky. Around 80% of smell instances are never removed, and refactoring occasionally introduces new smells rather than removing them.
The practical implication: the run-up to a release is the highest-risk window for smell accumulation, and the files most worth watching are the newest and the most heavily worked, not just the oldest. Because roughly 80% of smells persist once introduced, catching them at code-review time is far cheaper than removing them later.
Adam Tornhill's Your Code As A Crime Scene (Pragmatic Bookshelf, 2015) and Software Design X-Rays (2018) introduced the behavioural code analysis framework that became CodeScene. The core insight: static analysis finds smells in the code; behavioural analysis finds smells in the evolution of the code.
CodeScene's hotspot model combines two signals - how complex a file is and how often it changes - to find the code where complexity and developer effort coincide; ownership fragmentation is layered on as a separate knowledge-risk signal. The payoff is that defects concentrate tightly: CodeScene's published analysis reports cases where roughly 1.2% of the code accounts for around 45% of the bugs teams detect and fix, and prioritised hotspots (a few percent of the codebase) consistently carry a disproportionate share of both defects and development effort.
The temporal coupling dimension is particularly valuable: two files that are always modified in the same commits are temporally coupled, even if no static analysis tool finds a direct dependency. Temporal coupling reveals implicit shotgun surgery that static analysis misses.
Christian Bird, Nachiappan Nagappan, Brendan Murphy, Harald Gall, and Premkumar Devanbu's “Don't Touch My Code! Examining the Effects of Ownership on Software Quality” (FSE 2011, Microsoft Research) is one of the most cited papers in software quality research.
Key finding: the study measured ownership as the proportion of commits made by a component's top contributor, and classified anyone responsible for less than 5% of a component's commits as a “minor contributor.” Binaries with more minor contributors had significantly more pre- and post-release failures, while a higher top-owner proportion was associated with fewer failures - after controlling for known quality factors including component size. The analysis was run on the Windows Vista and Windows 7 codebases.
The implication for God Classes: a class that attracts contributions from authentication engineers, billing engineers, and notification engineers is structurally fragmented. The ownership fragmentation is a direct consequence of the class's accumulated responsibilities. The defect rate is a predictable outcome.
Victor Basili, Lionel Briand, and Walcelio Melo's “A Validation of Object-Oriented Design Metrics as Quality Indicators” (IEEE Transactions on Software Engineering, 1996) was the first rigorous empirical validation of the Chidamber-Kemerer metrics suite.
The study collected fault data from eight medium-sized information-management systems, all written in C++ to identical requirements by student teams at the University of Maryland, and found that Coupling Between Objects (CBO) and Response For a Class (RFC) were among the strongest predictors of fault-proneness. Weighted Methods per Class (WMC, a complexity proxy) was also predictive. Depth of Inheritance Tree (DIT) had mixed results.
Basili 1996 is the empirical backbone for Feature Envy and God Class cost estimates on this site. Both smells directly increase CBO - Feature Envy by creating outbound coupling, God Class by attracting inbound coupling.
Correlation is not causation
The research establishes correlation. A smell-dense class may be defect-prone because it is the hardest-worked part of the system, not because of the smell per se. Causal inference in software engineering research is genuinely hard.
Open-source selection bias
Most studies use open-source Java systems where defects are tracked in public issue trackers. These may not generalise to private enterprise codebases with different defect recording practices, different development cultures, and different levels of testing investment.
Tool detection vs human judgement gap
The 'smell detected by SonarCloud' and the 'smell as judged by an experienced engineer' are different things. Studies that rely on automated smell detection may measure the tool's false-positive rate as much as the smell's actual prevalence.
Publication bias
Studies that find no significant correlation between smells and defects are less likely to be published than studies that find a significant correlation. The literature may overstate effect sizes.
Prioritise active remediation for the strong- and moderate-association smells: God Class, Feature Envy, Duplicate Code, Long Method, Shotgun Surgery. These are the smells with the strongest and most replicated defect associations across the literature. For these smells, the business case for refactoring is empirically supported.
Accept that low-correlation smells (Comments, Data Class) may be stylistic preferences with limited defect impact. Do not spend engineering capital removing Comments smells when God Classes remain unaddressed.