A systematic literature review on the code smells datasets and validation mechanisms

The accuracy reported for code smell-detecting tools varies depending on the dataset used to evaluate the tools. Our survey of 45 existing datasets reveals that the adequacy of a dataset for detecting smells highly depends on relevant properties such as the size, severity level, project types, number of each type of smell, number of smells, and the ratio of smelly to non-smelly samples in the dataset. Most existing datasets support God Class, Long Method, and Feature Envy while six smells in Fowler and Beck's catalog are not supported by any datasets. We conclude that existing datasets suffer from imbalanced samples, lack of supporting severity level, and restriction to Java language.Comment: 34 pages, 10 figures, 12 tables, Accepte

A heuristic-based approach to code-smell detection

Encapsulation and data hiding are central tenets of the object oriented paradigm. Deciding what data and behaviour to form into a class and where to draw the line between its public and private details can make the difference between a class that is an understandable, flexible and reusable abstraction and one which is not. This decision is a difficult one and may easily result in poor encapsulation which can then have serious implications for a number of system qualities. It is often hard to identify such encapsulation problems within large software systems until they cause a maintenance problem (which is usually too late) and attempting to perform such analysis manually can also be tedious and error prone. Two of the common encapsulation problems that can arise as a consequence of this decomposition process are data classes and god classes. Typically, these two problems occur together – data classes are lacking in functionality that has typically been sucked into an over-complicated and domineering god class. This paper describes the architecture of a tool which automatically detects data and god classes that has been developed as a plug-in for the Eclipse IDE. The technique has been evaluated in a controlled study on two large open source systems which compare the tool results to similar work by Marinescu, who employs a metrics-based approach to detecting such features. The study provides some valuable insights into the strengths and weaknesses of the two approache

Mining and Managing Big Data Refactoring for Design Improvement: Are We There Yet?

Refactoring is a set of code changes applied to improve the internal structure of a program, without altering its external behavior. With the rise of continuous integration and the awareness of the necessity of managing technical debt, refactoring has become even more popular in recent software builds. Recent studies indicate that developers often perform refactorings. If we consider all refactorings performed across all projects, this consists of the refactoring knowledge that represents a rich source of information that can be useful for both developers and practitioners to better understand how refactoring is being applied in practice. However, mining, processing, and extracting useful insights, from this plethora of refactorings, seems to be challenging. In this book chapter, we take a dive into how refactoring can be mined and preprocessed. We discuss all design concepts and structural metrics that can also be mined along with refactoring operations to understand their impact better. We further investigate the many practical challenges for such extraction. The volume, velocity, and variety of extracted data require careful planning. We outline the appropriate techniques from a large number of available technologies for such system implementation

Detecting sudden variations in web apps code smells’ density: A longitudinal study

Code smells are considered potentially harmful to software maintenance. Their introduction is dependent on the production of new code or the addition of smelly code produced by another team. Code smells survive until being refactored or the code where they stand is removed. Under normal conditions, we expect code smells density to be relatively stable throughout time. Anomalous (sudden) increases in this density are expected to hurt maintenance costs and the other way round. In the case of sudden increases, especially in pre-release tests in an automation server pipeline, detecting those outlier situations can trigger refactoring actions before releasing the new version. This paper presents a longitudinal study on the sudden variations in the introduction and removal of 18 server code smells on 8 PHP web apps, across several years. The study regards web applications but can be generalized to other domains, using other CS and tools. We propose a standardized detection criterion for this kind of code smell anomalies. Besides providing a retrospective view of the code smell evolution phenomenon, our detection approach, which is particularly amenable to graphical monitoring, can make software project managers aware of the need for enforcing refactoring actions.info:eu-repo/semantics/publishedVersio

On Increasing Trust Between Developers and Automated Refactoring Tools Through Visualization

In software development, maintaining good design is essential. The process of refactoring enables developers to improve this design during development without altering the program’s existing behavior. However, this process can be time-consuming, introduce semantic errors, and be difficult for developers inexperienced with refactoring or unfamiliar with a given code base. Automated refactoring tools can help not only by applying these changes, but by identifying opportunities for refactoring. Yet, developers have not been quick to adopt these tools due to a lack of trust between the developer and the tool. We propose an approach in the form of a visualization to aid developers in understanding these suggested operations and increasing familiarity with automated refactoring tools. We also provide a manual validation of this approach and identify options to continue experimentation

Mining Sequences of Developer Interactions in Visual Studio for Usage Smells

In this paper, we present a semi-automatic approach for mining a large-scale dataset of IDE interactions to extract usage smells, i.e., inefficient IDE usage patterns exhibited by developers in the field. The approach outlined in this paper first mines frequent IDE usage patterns, filtered via a set of thresholds and by the authors, that are subsequently supported (or disputed) using a developer survey, in order to form usage smells. In contrast with conventional mining of IDE usage data, our approach identifies time-ordered sequences of developer actions that are exhibited by many developers in the field. This pattern mining workflow is resilient to the ample noise present in IDE datasets due to the mix of actions and events that these datasets typically contain. We identify usage patterns and smells that contribute to the understanding of the usability of Visual Studio for debugging, code search, and active file navigation, and, more broadly, to the understanding of developer behavior during these software development activities. Among our findings is the discovery that developers are reluctant to use conditional breakpoints when debugging, due to perceived IDE performance problems as well as due to the lack of error checking in specifying the conditional