[Paper] The Influence of Code Smells in Efferent Neighbors on Class Stability

Source: arXiv - 2602.12950v1

Overview

The paper investigates a hidden source of software instability: code smells that live in the classes a given class depends on (its efferent neighbors). While most prior work looks only at smells inside the class being changed, the authors show that “ripple‑effects” from smelly dependencies—and the way smells interact across those dependencies—can significantly degrade class stability. By mining a year of commits from 100 popular open‑source projects, they quantify how these external smells predict the frequency and size of future changes.

Key Contributions

• Empirical evidence that efferent‑neighbor smells matter: Demonstrates that code smells in dependent classes increase the likelihood that a clean class will become unstable.
• Definition and measurement of “code smell interrelation” and “code smell interaction”: Introduces formal metrics to capture how smells co‑occur across static dependency edges.
• Large‑scale dataset: Analyzes 100 top‑starred GitHub repositories (≈ 1 M+ classes, > 10 M+ commits) with a year‑long history, providing a robust empirical foundation.
• Predictive models for class stability: Builds regression and survival‑analysis models that incorporate neighbor‑smell features, achieving statistically significant improvements over baseline models that consider only intra‑class smells.
• Practical guidelines for developers and tool builders: Offers actionable insights on where to focus refactoring effort to curb future instability.

Methodology

1. Project Selection & Data Collection – The authors selected the 100 most‑starred GitHub Java projects, cloned each repository, and extracted a full year of commit history (author, timestamp, modified files).
2. Static Analysis – Using the SpotBugs and PMD rule sets, they detected a suite of common smells (e.g., God Class, Long Method, Feature Envy). Dependency graphs were built with JDepend to identify efferent (outgoing) edges for every class.
3. Defining Interrelation & Interaction
   • Interrelation: Count of distinct smell types that appear together either within a class or across a dependency edge.
   • Interaction: Binary flag indicating whether two directly connected classes each contain at least one smell, creating a “smell‑to‑smell” link.
4. Stability Metric – For each class, stability is measured as the number of commits that modify the class (or its public API) per month, normalized by its size (LOC).
5. Modeling – The authors fit multiple linear regression and Cox proportional‑hazard models, using predictors such as:
   (i) intra‑class smell count,
   (ii) total smell count in efferent neighbors,
   (iii) interrelation score, and
   (iv) interaction flag.
   Model performance is evaluated via R², AIC, and cross‑validation.
6. Statistical Validation – Hypothesis tests (Wilcoxon, Mann‑Whitney) and effect‑size calculations confirm that neighbor‑smell variables have a non‑trivial impact on stability.

Results & Findings

In short, the presence of smells outside a class—especially when those smells are linked across dependencies—has a measurable, adverse impact on how often the class needs to be changed.

Practical Implications

• Prioritize refactoring of smelly dependencies – Tools that surface “hot‑spot” classes should also surface their efferent smelly neighbors. Fixing a God Class that many other classes depend on can reduce churn across the whole module.
• Dependency‑aware code‑review checklists – Reviewers can flag PRs that modify a class whose dependencies are known to be smelly, prompting extra testing or a quick sanity check.
• Automated stability dashboards – Integrate the paper’s metrics (neighbor smell count, interrelation score) into CI dashboards to predict future maintenance effort and allocate resources proactively.
• Architecture‑level decisions – When designing micro‑services or modular libraries, aim for low‑smell public APIs; a clean API surrounded by smelly internal components still drags down client stability.
• Tooling extensions – Existing static analysis plugins (e.g., SonarQube, IntelliJ inspections) can be extended to compute “smell interaction heatmaps” that visualize clusters of interrelated smells across the dependency graph.

Limitations & Future Work

• Language & ecosystem focus: The study is limited to Java projects; other languages with different dependency mechanisms (e.g., dynamic imports in JavaScript) may exhibit different patterns.
• Static dependencies only: Runtime or reflective dependencies are not captured, potentially under‑estimating ripple effects in frameworks that rely heavily on reflection or DI containers.
• Commit frequency as a proxy for instability: While widely used, commit count does not differentiate between trivial and substantial changes; future work could incorporate change‑size metrics or issue‑tracker data.
• Causal inference: The analysis is correlational; controlled experiments or longitudinal interventions (e.g., targeted refactoring) would be needed to confirm causality.
• Broader smell taxonomy: The authors used a fixed set of popular smells; exploring newer or domain‑specific smells (e.g., security‑related anti‑patterns) could extend the findings.

Bottom line: By looking beyond the “inside” of a class and accounting for the health of its neighbors, developers can more accurately predict and mitigate future maintenance headaches. This research opens the door for smarter, dependency‑aware quality tools that keep codebases stable—and developers happier.

Authors

• Zushuai Zhang
• Elliott Wen
• Ewan Tempero

Paper Information

• arXiv ID: 2602.12950v1
• Categories: cs.SE
• Published: February 13, 2026
• PDF: Download PDF