Organizing the Technical Debt Landscape

To date, several methods and tools for detecting source code and design anomalies have been developed. While each method focuses on identifying certain classes of source code anomalies that potentially relate to technical debt (TD), the overlaps and gaps among these classes and TD have not been rigorously demonstrated. We propose to construct a seminal technical debt landscape as a way to visualize and organize research on the subjec

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.

Structured Review of the Evidence for Effects of Code Duplication on Software Quality

This report presents the detailed steps and results of a structured review of code clone literature. The aim of the review is to investigate the evidence for the claim that code duplication has a negative effect on code changeability. This report contains only the details of the review for which there is not enough place to include them in the companion paper published at a conference (Hordijk, Ponisio et al. 2009 - Harmfulness of Code Duplication - A Structured Review of the Evidence)

Mutation Testing as a Safety Net for Test Code Refactoring

Refactoring is an activity that improves the internal structure of the code without altering its external behavior. When performed on the production code, the tests can be used to verify that the external behavior of the production code is preserved. However, when the refactoring is performed on test code, there is no safety net that assures that the external behavior of the test code is preserved. In this paper, we propose to adopt mutation testing as a means to verify if the behavior of the test code is preserved after refactoring. Moreover, we also show how this approach can be used to identify the part of the test code which is improperly refactored