An Event-Driven Tool for Context-Aware Code Smell Detection Using SmellDSL
Pith reviewed 2026-05-21 04:20 UTC · model grok-4.3
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.
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
- 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
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.
Referee Report
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)
- [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)
- [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.
- [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
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
-
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
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
axioms (1)
- domain assumption Contextual information (team characteristics, project stage, geographic metadata) improves the actionability of code smell warnings for refactoring decisions.
Lean theorems connected to this paper
-
IndisputableMonolith/Cost/FunctionalEquation.leanwashburn_uniqueness_aczel unclear?
unclearRelation between the paper passage and the cited Recognition theorem.
SmellHunter integrates static code metrics with contextual information (such as team characteristics, project stage, and geographic metadata) to produce richer, more actionable analyses.
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
- [1]
- [2]
-
[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
work page 2019
-
[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]
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]
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]
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]
- [9]
-
[10]
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
work page 2022
-
[11]
G. Suryanarayana, G. Samarthyam, T. Sharma, Refactor- ing for software design smells: managing technical debt, Morgan Kaufmann, 2014
work page 2014
-
[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
work page 2020
-
[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
work page 2020
-
[14]
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)
work page 2023
-
[15]
Stopford, Designing event-driven systems, O’Reilly Media, Incorporated, 2018
B. Stopford, Designing event-driven systems, O’Reilly Media, Incorporated, 2018
work page 2018
-
[16]
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]
C. E. Carbonera, K. Farias, V . Bischoff, Software develop- ment effort estimation: a systematic mapping study, IET Software 14 (4) (2020) 328–344
work page 2020
-
[18]
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
work page 2021
- [19]
-
[20]
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
work page 2023
-
[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
work page 2022
-
[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
work page 2023
discussion (0)
Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.