Search

Several kinds of smells have been defined in the literature, but no formal definition exists. Hence, the code smells detection tools provide different results, because the smells can be interpreted and detected in different ways. Moreover, other aspects related to the domain of the system under analysis, or its size and other design features are not usually taken into account. For these reasons the detected smells may not always be real smells and symptoms of problems to be solved. In this paper we address this question on the evaluation of smells. We focus our attention on the detection of two smells, God Class and Data Class on different systems, with the aim to identify possible filters to be used to improve or refine the detection rules of these smells. By identifying only real smells, the refactoring effort to inspect and remove them is reduced.

Code smells indicate possible flaws in software design, that could negatively affect system’s maintainability. Interactions among smells located in the same classes (i.e., collocated smells) have even more detrimental effect on quality. Extracted frequent patterns of collocated smells could help to understand practical consequences of collocations. In this paper we identify and empirically validate frequent collocations of 14 code smells detected in 92 Java systems, using three approaches: pairwise correlation analysis, PCA and associative rules. To cross-validate the results, we used up to 6 detectors for each smell. Additionally, we examine and compare techniques used to extract the relationships. The contribution is three-fold: (1) we identify and empirically validate relationships among the examined code smells on a large dataset that we made publicly available, (2) we discuss how the choice of code smell detectors affects results, and (3) we analyze the impact of software domain on existence of the smell collocations. Additionally, we found that analytical methods we used to discover collocations, are complementary. Smells collocations display recurring patterns that could help prioritizing the classes affected by code smells to be refactored and developing or enhancing detectors exploiting information about collocations. They can also help the developers focusing on classes deserving more maintenance effort.

We can evaluate software architecture quality using a plethora of metrics proposed in the literature, but interpreting and exploiting in the right way these metrics is not always a simple task. This is true for both fixing the right metric threshold values and determining the actions to be taken to improve the quality of the system. Instead of metrics, we can detect code or architectural anomalies that give us useful hints on the possible architecture degradation. In this paper, we focus our attention on the detection of code smells and in particular on their relations and co-occurrences, with the aim to evaluate technical debt in an architectural context. We start from the assumption that certain patterns of code anomalies tend to be better indicators of architectural degradation than simple metrics evaluation.

Many tools for code smell detection have been devel- oped, providing often different results. This is due to the informal definition of code smells and to the subjective interpretation of them. Usually, aspects related to the domain, size, and design of the system are not taken into account when detecting and analyzing smells. These aspects can be used to filter out the noise and achieve more relevant results. In this paper, we propose different filters that we have identified for five code smells. We provide two kind of filters, Strong and Weak Filters, that can be integrated as part of a detection approach.

Code smells can be used to capture symptoms of code decay and potential maintenance problems that can be avoided by applying the right refactoring. They can be seen as a source of technical debt. However, tools for code smell detection often provide far too many and different results, and identify many false positive code smell instances. In fact, these tools are rooted on initial and rather informal code smell definitions. This represents a challenge to interpret their results in different ways. In this paper, we provide an Intensity Index, to be used as an estimator to determine the most critical instances, prioritizing the examination of smells and, potentially, their removal. We apply Intensity on the detection of six well known and common smells and we report their Intensity distribution from an analysis performed on 74 systems of the Qualitas Corpus, showing how Intensity could be used to prioritize code smells inspection.

There are various activities that support software maintenance. Program comprehension and detection of design anomalies and their symptoms, like code smells and anti patterns, are particularly relevant for improving the quality and facilitating evolution of a system. In this paper we describe an empirical study on the detection of code smells, aiming at identifying the most frequent smells in systems of different domains and hence the domains characterized by more smells. Moreover, we study possible correlations existing among smells and the values of a set of software quality metrics using Spearman's rank correlation and Principal Component Analysis.