Are Smell-Based Metrics Actually Useful in Effort-Aware Structural Change-Proneness Prediction? An Empirical Study

Bad code smells (also named as code smells) are symptoms of poor design choices in implementation. Existing studies empirically confirmed that the presence of code smells increases the likelihood of subsequent changes (i.e., change-proness). However, to the best of our knowledge, no prior studies have leveraged smell-based metrics to predict particular change type (i.e., structural changes). Moreover, when evaluating the effectiveness of smell-based metrics in structural change-proneness prediction, none of existing studies take into account of the effort inspecting those change-prone source code. In this paper, we consider five smell-based metrics for effort-aware structural change-proneness prediction and compare these metrics with a baseline of well-known CK metrics in predicting particular categories of change types. Specifically, we first employ univariate logistic regression to analyze the correlation between each smellbased metric and structural change-proneness. Then, we build multivariate prediction models to examine the effectiveness of smell-based metrics in effort-aware structural change-proneness prediction when used alone and used together with the baseline metrics, respectively. Our experiments are conducted on six Java open-source projects with up to 60 versions and results indicate that: (1) all smell-based metrics are significantly related to structural change-proneness, except metric ANS in hive and SCM in camel after removing confounding effect of file size; (2) in most cases, smell-based metrics outperform the baseline metrics in predicting structural change-proneness; and (3) when used together with the baseline metrics, the smell-based metrics are more effective to predict change-prone files with being aware of inspection effort

Understanding the Correlation between Code Smells And Software Bugs

https://deepblue.lib.umich.edu/bitstream/2027.42/147342/1/CodeSmellsBugs.pd

An Empirical Study of the Correlation between Code Smells And Software Bugs

Bug predictions helps software quality assurance team to determine the effort required to test the software application. Anti-patterns and code smells can greatly influence the quality of the code. Refactoring can be a solution to remove the negative impact of these anti-patterns. In this paper, we explored the influence of code smells on the code and severity of bugs reported on multiple versions of the projects such as BIRT, Aspect J and SWT. We evaluated the correlation between the different code smells and severity of the bugs reported on these classes. This can help the quality assurance specialists and project managers assess the testing effort required based on the code smells detected. This can prove beneficial to the developers to restructure or refactor before deploying the code in the test environment. On the other hand, the testing team can concentrate on the bug prediction models, testing plan and assess the number of resources needed to perform testing. The empirical validation of our work found a strong correlation between several types of code smells and software bugs based on three large open source projects.Master of ScienceSoftware Engineering, College of Engineering & Computer ScienceUniversity of Michigan-Dearbornhttps://deepblue.lib.umich.edu/bitstream/2027.42/147432/1/Dec 19- Thesis Report_GANESAN GAYATHRI_4pm_FontsEmbedded.pdfDescription of Dec 19- Thesis Report_GANESAN GAYATHRI_4pm_FontsEmbedded.pdf : Thesi

On the relation between architectural smells and source code changes

Although architectural smells are one of the most studied type of architectural technical debt, their impact on maintenance effort has not been thoroughly investigated. Studying this impact would help to understand how much technical debt interest is being paid due to the existence of architecture smells and how this interest can be calculated. This work is a first attempt to address this issue by investigating the relation between architecture smells and source code changes. Specifically, we study whether the frequency and size of changes are correlated with the presence of a selected set of architectural smells. We detect architectural smells using the Arcan tool, which detects architectural smells by building a dependency graph of the system analyzed and then looking for the typical structures of the architectural smells. The findings, based on a case study of 31 open-source Java systems, show that 87% of the analyzed commits present more changes in artifacts with at least one smell, and the likelihood of changing increases with the number of smells. Moreover, there is also evidence to confirm that change frequency increases after the introduction of a smell and that the size of changes is also larger in smelly artifacts. These findings hold true especially in Medium–Large and Large artifacts

An exploratory study of the impact of code smells on software change-proneness,”

Abstract Context and Problem In theory, code smells [12] are poor implementation choices, opposite to idioms [8] and, to some extent, to design patterns [13]. They are "poor" solutions to recurring implementation problems. In practice, code smells are inbetween design and implementation: they may concern the design of a class, but they concretely manifest themselves in the source code as classes with specific implementation. They are usually revealed through particular metric values [22]. One example of a code smell is the ComplexClassOnly smell, which occurs in classes with a very high McCabe complexity when compared to other class in a system. At a higher level of abstraction, the presence of some specific code smells can, in turn, manifest in antipatterns [5], of which code smells are parts of. Studying the effects of antipatterns is, however, out of scope of this study and will be treated in other works. Premise. Code smells are conjectured in the literature to hinder object-oriented software evolution. Yet, despite the existence of many works on code smells and antipatterns, no previous work has contrasted the change-proneness of classes with code smells with this of other classes to study empirically the impact of code smells on this aspect of software evolution. Goal. We want to investigate the relations between these code smells and three types of code evolution phenomena. First, we study whether classes with code smells have an increased likelihood of changing than other classes. Second, we study whether classes with more smells than others are more change-prone. Third, we study the relation between particular smells and change-proneness. Contribution. We present an exploratory study investigating the relations between 29 code smells and changes occurring to classes in 9 releases of Azureus and 13 releases of Eclipse. We show that code smells do have a negative impact on classes, that certain kinds of smells do impact classes more than others, and that classes with more smells exhibit higher change-proneness. Relevance. Understanding if code smells increase the risk of classes to change is important from the points of view of both researchers and practitioners. We bring evidence to researchers that (1) code smells do increase the number of changes that classes undergo, (2) the more smells a class has, the more change-prone it is, and (3) certain smells lead to more change-proneness than others. Therefore, this study justifies a posteriori previous work on code smells: within the limits of the threats to its validity, classes with code smells are more change-prone than others and therefore smells may indeed hinder software evolution; 1 we empirically support such a conjecture reported in the literature [12, 21, 32], which is the premise of this study. We also provide evidence to practitioners-developers, quality assurance personnel, and managers-of the importance and usefulness of code smells detection techniques to assess the quality of their systems by showing that classes with smells are more likely to change often, thus impacting on the maintenance effort. Organisation. Section 2 relates our study with previous works. Section 3 provides definitions and a description of our specification and detection approach for code smells. Section 4 describes the exploratory study definition and design. Section 5 presents the study results, while Section 6 discusses them, along with threats to their validity. Finally, Section 7 concludes the study and outlines future work. Related Work Several works studied code smells, often in relation to antipatterns. We summarise these works as well as works aimed at relating metrics with software change-proneness. Code Smell Definition and Detection. The first book on "antipatterns" in object-oriented development was written in 1995 by Webster [33]; his contribution includes conceptual, political, coding, and quality-assurance problems. Riel [25] defined 61 heuristics characterising good objectoriented programming to assess a system quality manually and improve its design and implementation. These heuristics are similar and-or precursor to code smells. Beck [12] defined 22 code smells, suggesting where developers should apply refactorings. Mäntylä [21] and Wake [32] proposed classifications for code smells. Brown et al. [5] described 40 antipatterns, which are often described in terms of lowerlevel code smells. These books provide in-depth views on heuristics, code smells, and antipatterns aimed at a wide academic audience. They are the basis of all the approaches to specify and (semi-)automatically detect code smells (and antipatterns). Several works proposed approaches to specify and detect code smells and antipatterns. They range from manual approaches, based on inspection techniques [29], to metricbased heuristics [22, 24], where code smells and-or antipatterns are identified according to sets of rules and thresholds defined on various metrics. Rules may also be defined using fuzzy logic and executed by means of a rule-inference engine [1] or using visualisation techniques [9, 27]. Semi-automatic approaches are an interesting compromise between fully automatic detection techniques that can be efficient but loose track of the context and manual inspections that are slow and subjective [19]. However, they require human expertise and are thus time-consuming. Other approaches perform fully automatic detection and use visualisation techniques to present the detection results [20, 30]. This previous work has contributed significantly to the specification and automatic detection of code smells and antipatterns. The approach used in this study, DECOR, builds on this previous work and offers a complete method to specify code smells and antipatterns and automatically detect them. Design Patterns and Software Evolution. While code smells and antipatterns represent "poor" implementation and-or design choices, design patterns are considered to be "good" solutions to recurring design problems. Nevertheless, they may not always have positive effects on a system. Vokac [31] analysed the corrective maintenance of a large commercial system over three years and compared the fault rates of classes that participated in design patterns against those of classes that did not. He noticed that participating classes were less fault prone than others. Vokac's work inspired us in the use of logistic regression to analyse the correlations between code smells and change-proneness. Bieman et al. While previous works investigated the impact of good design principles, i.e., design patterns, on systems, we study the impact of poor implementation choices, i.e., code smells, on software evolution. Metrics and Software Evolution. Several studies, such as Basili et al.'s seminal work [3], used metrics as quality indicators. Cartwright and Shepperd [6] conducted an empirical study on an industrial C++ system (over 133 KLOC), which supported the hypothesis that classes in inheritance relations are more fault prone. It followed that Chidamber and Kemerer DIT and NOC metrics [7] could be used to find classes that are likely to have higher fault rates. Gyimothy et al. [15] compared the capability of sets of Chidamber and Kemerer metrics to predict fault-prone classes within Mozilla, using logistic regression and other machine learning techniques, e.g., artificial neural networks. They concluded that CBO is the most discriminating metric. They also found LOC to discriminate fault-prone classes well. Zimmermann et al. [36] conducted an empirical study on Eclipse showing that a combination of complexity metrics can predict faults and suggesting that the more complex the code, the more faults. El Emam et al. [11] showed that after controlling for the confounding effect of size, the correlation between metrics and fault-proneness disappeared: many metrics are correlated with size and, therefore, do not bring more information to predict fault proneness.

Detailed Overview of Software Smells

This document provides an overview of literature concerning software smells covering various dimensions of smells along with their corresponding references

An exploratory study of the impact of software changeability

Antipatterns are poor design choices that make object-oriented systems hard to maintain by developers. In this study, we investigate if classes that participate in antipatterns are more change-prone than classes that do not. Specifically, we test the general hypothesis: classes belonging to antipatterns are not more likely than other classes to undergo changes, to be impacted when fixing issues posted in issue- tracking systems, and in particular to unhandled exceptions-related issues - a crucial problem for any software system. We detect 11 antipatterns in 13 releases of Eclipse and study the relations between classes involved in these antipatterns and classes change-, issue-, and unhandled exception-proneness. We show that, in almost all releases of Eclipse, classes with antipatterns are more change-, issue-, and unhandled-exception-prone than others. These results justify previous work on the specification and detection of antipatterns and could help focusing quality assurance and testing activities