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.

While much work has focused on continuously publishing Linked Open Data, little work considers how to help consumers to better understand existing datasets. ABSTAT framework aims at providing a better understanding of big and complex datasets by extracting summaries of linked data sets based on an ontology-driven data abstraction model. Our ABSTAT framework takes as input a data set and an ontology and returns an ontology-driven data summary as output. The summary is exported into RDF and then made accessible through a SPARQL endpoint and a web interface to support the navigation.

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.

Code smells are archetypes of design shortcomings in the code that can potentially cause problems during maintenance. One known approach for detecting code smells is via detection rules: a combination of different object-oriented metrics with pre-defined threshold values. The usage of inadequate thresholds when using this approach could lead to either having too few observations (too many false negatives) or too many observations (too many false positives). Furthermore, without a clear methodology for deriving thresholds, one is left with those suggested in literature (or by the tool vendors), which may not necessarily be suitable to the context of analysis. In this paper, we propose a data-driven (i.e., benchmark-based) method to derive threshold values for code metrics, which can be used for implementing detection rules for code smells. Our method is transparent, repeatable and enables the extraction of thresholds that respect the statistical properties of the metric in question (such as scale and distribution). Thus, our approach enables the calibration of code smell detection rules by selecting relevant systems as benchmark data. To illustrate our approach, we generated a benchmark dataset based on 74 systems of the Qualitas Corpus, and extracted the thresholds for five smell detection rules.

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.

Different forms of technical debt exist that have to be carefully managed. In this paper we focus our attention on design debt, represented by code smells. We consider three smells that we detect in open source systems of different domains. Our principal aim is to give advice on which design debt has to be paid first, according to the three smells we have analyzed. Moreover we discuss if the detection of these smells could be tailored to the specific application domain of a system.