Toward a Smell-Aware Bug Prediction Model

Abstract

Code smells are symptoms of poor design and implementation choices. Previous studies empirically assessed the impact of smells on code quality and clearly indicate their negative impact on maintainability, including a higher bug-proneness of components affected by code smells. In this paper, we capture previous findings on bug-proneness to build a specialized bug prediction model for smelly classes. Specifically, we evaluate the contribution of a measure of the severity of code smells (i.e., code smell intensity) by adding it to existing bug prediction models based on both product and process metrics, and comparing the results of the new model against the baseline models. Results indicate that the accuracy of a bug prediction model increases by adding the code smell intensity as predictor. We also compare the results achieved by the proposed model with the ones of an alternative technique which considers metrics about the history of code smells in files, finding that our model works generally better. However, we observed interesting complementarities between the set of buggy and smelly classes correctly classified by the two models. By evaluating the actual information gain provided by the intensity index with respect to the other metrics in the model, we found that the intensity index is a relevant feature for both product and process metrics-based models. At the same time, the metric counting the average number of code smells in previous versions of a class considered by the alternative model is also able to reduce the entropy of the model. On the basis of this result, we devise and evaluate a smell-aware combined bug prediction model that included product, process, and smell-related features.We demonstrate how such model classifies bug-prone code components with an F-Measure at least 13% higher than the existing state-of-the-art models.

Improving change prediction models with code smell-related information

“…Looking at the ranking, we also noticed that Response For a Class (RFC), Lines of Code (LOC), and Lack of Cohesion of Methods (LCOM3) appear to be relevant. On the one hand, this is still in line with previous findings [12,85,128]. On the other hand, it is also important to note that our results seem to reconsider the role of code size for assessing change prediction.…”

“…At the same time, the antipattern metrics-including models were confirmed to provide statistically better performance than the basic models in 67% of the considered systems. [85] as a predictor of change-prone components increases the performance of the baseline change prediction models in terms of F-Measure up to 10%.…”

“…To compute these metrics, we employed the tool developed by Palomba et al [85]. Then, as done in the context of RQ 1 , we plugged the antipattern metrics into the experimented baselines and assess the performance of the resulting change prediction models using the same set of evaluation metrics described in Section 3.3.7, i.e., F-Measure and AUC-ROC.…”

“…All in all, this selection process allowed us to test the contribution of smell-related information in different contexts. As for the dataset, we relied on a publicly available source previously built [85]. Of course, we cannot exclude possible imprecisions in the computation of the dependent variable.…”

How is video game development different from software development in open source?

“…(3) Game-specific fault localization. Current approaches for detecting faults mainly target source code artifacts [13,24,36], while game development calls for different approaches in order to properly support developers in preventively adopt corrective actions. Practitioners need to find appropriate ways to handle requirements, possibly closely involving end users during the whole software lifecycle, e.g., by finding ways to ease communication with them as also mandated by Agile methodologies.…”