Less is More: Minimizing Code Reorganization using XTREE

TL;DR

This paper introduces XTREE, a tool that analyzes historical defect data to recommend minimal, effective code changes, reducing unnecessary reorganization and focusing on impactful bad smells to improve software quality.

Contribution

XTREE provides a data-driven approach to identify which bad code smells are truly linked to defects, enabling targeted and minimal code reorganization based on historical defect records.

Findings

Modules changed per XTREE have fewer defects.

XTREE recommends changes to fewer code metrics.

Not all traditional bad smells are relevant across projects.

Abstract

Context: Developers use bad code smells to guide code reorganization. Yet developers, text books, tools, and researchers disagree on which bad smells are important. Objective: To evaluate the likelihood that a code reorganization to address bad code smells will yield improvement in the defect-proneness of the code. Method: We introduce XTREE, a tool that analyzes a historical log of defects seen previously in the code and generates a set of useful code changes. Any bad smell that requires changes outside of that set can be deprioritized (since there is no historical evidence that the bad smell causes any problems). Evaluation: We evaluate XTREE's recommendations for bad smell improvement against recommendations from previous work (Shatnawi, Alves, and Borges) using multiple data sets of code metrics and defect counts. Results: Code modules that are changed in response to XTREE's recommendations contain significantly fewer defects than recommendations from previous studies. Further, XTREE endorses changes to very few code metrics, and the bad smell recommendations (learned from previous studies) are not universal to all software projects. Conclusion: Before undertaking a code reorganization based on a bad smell report, use a tool like XTREE to check and ignore any such operations that are useless; i.e. ones which lack evidence in the historical record that it is useful to make that change. Note that this use case applies to both manual code reorganizations proposed by developers as well as those conducted by automatic methods. This recommendation assumes that there is an historical record. If none exists, then the results of this paper could be used as a guide.