pith. sign in

arxiv: 2605.20675 · v1 · pith:AQFKXXENnew · submitted 2026-05-20 · 💻 cs.SE

An Event-Driven Tool for Context-Aware Code Smell Detection Using SmellDSL

Pith reviewed 2026-05-21 04:20 UTC · model grok-4.3

classification 💻 cs.SE
keywords code smellscontext-aware detectionSmellDSLevent-driven architecturerefactoring supportsoftware qualityEclipse pluginmobile visualization
0
0 comments X

The pith

SmellHunter combines static code metrics with team, project, and location context to produce more actionable code smell analyses.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces SmellHunter, a tool designed to detect code smells while accounting for the surrounding development context that traditional metric-based tools ignore. It claims that linking smells to details like team characteristics, project stage, and geographic metadata helps teams avoid misleading warnings and make better choices about what to refactor. SmellHunter achieves this through scripts written in the SmellDSL language, which are processed by an event-driven architecture that uses a service bus to handle validation, interpretation, and data storage asynchronously. The system integrates directly into the Eclipse environment and offers a mobile app for viewing aggregated results by smell type, severity, and location. This setup supports assigning refactoring work to developers with matching expertise and spotting patterns tied to specific contexts.

Core claim

SmellHunter interprets SmellDSL scripts within an event-driven architecture to integrate static code metrics with contextual information such as team characteristics, project stage, and geographic metadata, thereby generating richer analyses that help teams identify recurring quality issues and assign refactoring tasks to appropriate developers.

What carries the argument

SmellDSL, a domain-specific language for defining context-aware smell detection rules, executed through an event-driven service bus that orchestrates asynchronous validation, interpretation, and persistence services.

If this is right

  • Refactoring tasks can be assigned to developers whose expertise matches the contextual signals attached to each smell.
  • The asynchronous event bus supports scalable smell analysis without interrupting ongoing development work.
  • Aggregated views in the mobile app and Eclipse plugin reveal patterns of smells linked to specific locations or project phases.
  • Teams gain the ability to track quality issues that recur in particular geographic or organizational contexts.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same contextual layering could be applied to detect and prioritize other maintenance concerns such as security risks or performance issues.
  • Accumulated context data over multiple projects might eventually allow the tool to forecast which smells are likely to become problematic in later stages.
  • Mobile visualization of context-linked smells could support distributed teams in coordinating fixes across time zones.

Load-bearing premise

That adding contextual data about teams, project stages, and locations will meaningfully improve the quality of refactoring decisions compared with static-metric-only tools.

What would settle it

A side-by-side study tracking whether developers using SmellHunter complete more successful or timely refactorings than developers using a static-metrics-only version of the same detection logic.

Figures

Figures reproduced from arXiv: 2605.20675 by Adrian Gabriel Keller dos Santos, Kleinner Farias, Matheus dos Santos Viegas, Robson Keemps da Silva.

Figure 1
Figure 1. Figure 1: Event-driven architecture of SmellHunter. (A) Client environment composed of the SmellHunter Eclipse plugin and the SmellHunter mobile application. (B) Server environment containing validation, interpretation, and persistence services coordinated through the Smell Bus. 3. Event-driven smell detection pipeline: Smell detection requests are processed asynchronously through the Smell Bus, enabling scalable an… view at source ↗
Figure 2
Figure 2. Figure 2: Illustrative example of the SmellHunter interface in the Eclipse environment. (A) Project Explorer showing the structure of a SmellDSL project. (B) Input specification panel with SmellDSL script, metrics, and thresholds. (C) Metadata configuration in JSON format used in the analysis request. (D) Execution feedback indicating the detection of a God Class smell. (E) Histogram summarizing detected smells. (F)… view at source ↗
Figure 3
Figure 3. Figure 3: SmellHunter mobile application interface: (A) geolocation of detected bad smells, (B) list of detected smell types, and (C) dashboard summarizing smell occurrences. support for code quality management. Additionally, future work will extend SmellHunter toward more intelligent and adaptive software quality analysis envi￾ronments. One promising direction is to incorporate cogni￾tive and behavioral indicators … view at source ↗
read the original abstract

Code smells signal violations of design principles that degrade the internal quality of evolving software systems. Although many tools detect such anomalies using static metrics, they often ignore the development context in which smells arise and are resolved. This limitation can lead to misleading warnings and weak support for refactoring decisions. To address this problem, we present SmellHunter, a context-aware tool that interprets scripts written in the SmellDSL domain-specific language to detect and contextualize code smells. SmellHunter integrates static code metrics with contextual information (such as team characteristics, project stage, and geographic metadata) to produce richer, more actionable analyses. The tool adopts an event-driven architecture in which a service bus orchestrates validation, interpretation, and persistence services through asynchronous events. This architecture enables scalable analysis while minimizing disruption to developers' workflows. SmellHunter is integrated into the Eclipse development environment via a dedicated plugin and provides aggregated insights via a mobile application, allowing developers to explore smell occurrences by type, severity, and location. By linking smell detection with contextual data and collaborative visualization, SmellHunter supports developers acting as smell hunters, helping teams identify recurring quality issues emerging from a particular location and assign refactoring tasks to developers with relevant expertise. We describe the architecture of SmellHunter, the interpretation process of SmellDSL scripts, and the integration of contextual data to support more informed refactoring decisions in modern software development environments.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 2 minor

Summary. The paper presents SmellHunter, a context-aware code smell detection tool that interprets scripts in the SmellDSL domain-specific language. It combines static code metrics with contextual data such as team characteristics, project stage, and geographic metadata within an event-driven architecture orchestrated by a service bus. The implementation includes an Eclipse plugin for integration into developer workflows and a mobile application for aggregated visualization of smell occurrences by type, severity, and location, with the goal of supporting more informed refactoring decisions.

Significance. If the integration of contextual information demonstrably improves analysis quality, the work could advance software engineering practice by shifting code smell detection from purely static approaches toward context-sensitive ones that reduce misleading warnings and better align refactoring tasks with team expertise and project circumstances. The event-driven design and custom DSL interpreter constitute practical engineering contributions that could serve as a foundation for extensible quality tools.

major comments (1)
  1. [Abstract] Abstract: The assertion that SmellHunter produces 'richer, more actionable analyses' and 'supports developers acting as smell hunters' by linking smells to contextual data rests on architectural description alone; the manuscript reports no user studies, controlled experiments, before/after metrics on decision quality, false-positive rates, or comparisons against static-metric-only detectors to substantiate this central benefit.
minor comments (2)
  1. [Throughout] The manuscript would benefit from explicit section headings and a table summarizing the SmellDSL grammar or key event types to improve readability of the interpretation process.
  2. [Architecture description] Diagrams of the service bus orchestration and the mobile visualization interface are referenced but their clarity and labeling could be improved to better illustrate the asynchronous event flow.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive and detailed feedback. We address the single major comment below and have revised the manuscript to better align claims with the scope of the presented work.

read point-by-point responses
  1. Referee: [Abstract] Abstract: The assertion that SmellHunter produces 'richer, more actionable analyses' and 'supports developers acting as smell hunters' by linking smells to contextual data rests on architectural description alone; the manuscript reports no user studies, controlled experiments, before/after metrics on decision quality, false-positive rates, or comparisons against static-metric-only detectors to substantiate this central benefit.

    Authors: We agree that the manuscript provides no empirical evaluation to substantiate the benefits of context-aware detection. The paper describes the design and implementation of an event-driven tool, the SmellDSL interpreter, Eclipse integration, and mobile visualization; it does not include user studies, controlled experiments, or quantitative comparisons. The claims in the abstract reflect the design rationale for incorporating contextual data rather than measured outcomes. We will revise the abstract to employ more cautious phrasing (e.g., 'is designed to produce richer, more actionable analyses' and 'aims to support developers acting as smell hunters'). We will also add a new 'Limitations and Future Work' section that explicitly notes the absence of empirical validation and outlines planned studies, including comparisons against static-metric baselines and assessments of decision quality. revision: yes

Circularity Check

0 steps flagged

No circularity: tool-description paper with no derivations or fitted results

full rationale

The paper is a system-description manuscript that presents the event-driven architecture, SmellDSL interpreter, Eclipse plugin, and mobile visualization of SmellHunter. No equations, parameter-fitting steps, or derivation chains exist that could reduce a claimed result to its own inputs by construction. Motivations for context integration are stated as design goals rather than outputs of any self-referential process, and no load-bearing uniqueness theorems or ansatzes are imported via self-citation. The work is therefore self-contained as an implementation report.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The paper is a systems description with no free parameters, mathematical axioms, or invented physical entities; its claims rest on the domain assumption that contextual metadata improves refactoring decisions.

axioms (1)
  • domain assumption Contextual information (team characteristics, project stage, geographic metadata) improves the actionability of code smell warnings for refactoring decisions.
    Invoked in the abstract as the motivation for richer analyses and the tool's value proposition.

pith-pipeline@v0.9.0 · 5793 in / 1225 out tokens · 27896 ms · 2026-05-21T04:20:28.765609+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

22 extracted references · 22 canonical work pages

  1. [1]

    Nocera, S

    S. Nocera, S. Vegas, G. Scanniello, M. D. Penta, N. Ju- risto, Causal or correlational? a cohort study on the ef- fects of code smells on class change- and fault-proneness, in: 48th International Conference on Software Engineer- ing, 2026, pp. 1–12

  2. [2]

    Oizumi, A

    W. Oizumi, A. Garcia, L. da Silva Sousa, B. Cafeo, Y . Zhao, Code anomalies flock together: Exploring code anomaly agglomerations for locating design problems, in: Proceedings of the 38th international conference on soft- ware engineering, 2016, pp. 440–451

  3. [3]

    Fowler, Refactoring: Improving the Design of Existing Code, Addison-Wesley Professional, 2019

    M. Fowler, Refactoring: Improving the Design of Existing Code, Addison-Wesley Professional, 2019

  4. [4]

    R. H. Díaz Arrieta, B. L. D. Monroy, L. J. C. Heredia, A. G. V . Cobos, Global trends and empirical metrics in the evaluation of code smells and technical debt: A bib- liometric study, IEEE Access 13 (2025) 138143–138165. doi:10.1109/ACCESS.2025.3594657. 7

  5. [5]

    Martins, C

    J. Martins, C. Bezerra, A. Uchôa, A. Garcia, How do code smell co-occurrences removal impact internal quality at- tributes? a developers’ perspective, in: XXXV Brazilian Symposium on Software Engineering (SBES ’21), ACM, 2021, pp. 54–63.doi:10.1145/3474624.3474642

  6. [6]

    Tsantalis, A

    N. Tsantalis, A. Ketkar, D. Dig, Refactoringminer 2.0, IEEE Transactions on Software Engineering 48 (3) (2022) 930–950.doi:10.1109/TSE.2020.3007722

  7. [7]

    M. A. A. Hilmi, A. Puspaningrum, Darsih, D. O. Siahaan, H. S. Samosir, A. S. Rahma, Research trends, detection methods, practices, and challenges in code smell: A sys- tematic literature review, IEEE Access 11 (2023) 129536– 129551.doi:10.1109/ACCESS.2023.3334258

  8. [8]

    Keemps, K

    R. Keemps, K. Farias, R. Kunst, C. Carbonera, W. Bolzan, Smelldsl: A domain-specific language to assist developers in specifying code smell patterns, Information and Soft- ware Technology 184 (2025) 107760

  9. [9]

    Hozano, A

    M. Hozano, A. Garcia, B. Fonseca, E. Costa, Are you smelling it? investigating how similar developers detect code smells, Information and Software Technology 93 (2018) 130–146

  10. [10]

    Oliveira, W

    D. Oliveira, W. K. Assunção, A. Garcia, B. Fonseca, M. Ribeiro, Developers’ perception matters: machine learning to detect developer-sensitive smells, Empirical Software Engineering 27 (7) (2022) 195

  11. [11]

    Suryanarayana, G

    G. Suryanarayana, G. Samarthyam, T. Sharma, Refactor- ing for software design smells: managing technical debt, Morgan Kaufmann, 2014

  12. [12]

    L. F. D’Avila, K. Farias, J. L. V . Barbosa, Effects of con- textual information on maintenance effort: a controlled experiment, Journal of Systems and Software 159 (2020) 110443

  13. [13]

    L. F. D’Avila, J. L. V . Barbosa, K. S. F. de Oliveira, Sw-context: A model to improve developers’ situational awareness, IET Software 14 (5) (2020) 535–543

  14. [14]

    Albuquerque, E

    D. Albuquerque, E. Guimarães, M. Perkusich, et al., In- tegrating interactive detection of code smells into scrum: Feasibility, benefits, and challenges, Applied Sciences 13 (15) (2023)

  15. [15]

    Stopford, Designing event-driven systems, O’Reilly Media, Incorporated, 2018

    B. Stopford, Designing event-driven systems, O’Reilly Media, Incorporated, 2018

  16. [16]

    Pereira dos Reis, F

    J. Pereira dos Reis, F. Brito e Abreu, G. de Figueiredo Carneiro, et al., Code smells de- tection and visualization: A systematic literature review, Archives of Computational Methods in Engineering 29 (2022) 47–94.doi:10.1007/s11831-021-09566-x

  17. [17]

    C. E. Carbonera, K. Farias, V . Bischoff, Software develop- ment effort estimation: a systematic mapping study, IET Software 14 (4) (2020) 328–344

  18. [18]

    Gonçales, K

    L. Gonçales, K. Farias, B. C. da Silva, Measuring the cog- nitive load of software developers: An extended system- atic mapping study, Information and Software Technology (2021) 106563

  19. [19]

    Cabane, K

    H. Cabane, K. Farias, On the impact of event-driven ar- chitecture on performance: An exploratory study, Future Generation Computer Systems 153 (2024) 52–69

  20. [20]

    Lazzari, K

    L. Lazzari, K. Farias, Event-driven architecture and rest architectural style: An exploratory study on modularity, Journal of applied research and technology 21 (3) (2023) 338–351

  21. [21]

    E. W. Júnior, K. Farias, B. da Silva, On the use of uml in the brazilian industry: A survey, Journal of Software Engineering Research and Development 10 (2022) 10–1

  22. [22]

    R. K. Silva, K. Farias, R. Kunst, J. Dalzochio, An ap- proach based on machine learning for predicting software design problems, in: Proceedings of the XIX Brazilian Symposium on Information Systems, 2023, pp. 53–60. 8