Contemporary Approach for Technical Reckoning Code Smells Detection using Textual Analysis

Software Designers should be aware of address design smells that can evident as results of design and decision. In a software project, technical debt needs to be repaid habitually to avoid its accretion. Large technical debt significantly degrades the quality of the software system and affects the productivity of the development team. In tremendous cases, when the accumulated technical reckoning becomes so enormous that it cannot be paid off to any further extent the product has to be abandoned. In this paper, we bridge the gap analyzing to what coverage abstract information, extracted using textual analysis techniques, can be used to identify smells in source code. The proposed textual-based move toward for detecting smells in source code, fabricated as TACO (Textual Analysis for Code smell detection), has been instantiated for detecting the long parameter list smell and has been evaluated on three sampling Java open source projects. The results determined that TACO is able to indentified between 50% and 77% of the smell instances with a exactitude ranging between 63% and 67%. In addition, the results show that TACO identifies smells that are not recognized by approaches based on exclusively structural information

INVESTIGANDO A IMPLEMENTAÇÃO DE CONCEITOS DE COESÃO E ACOPLAMENTO NA PRÁTICA DE DESENVOLVIMENTO DE SOFTWARE ORIENTADO A OBJETOS

O conceito de anomalia de código vem sendo aceito desde a década de 90 como umindicativo de problemas em projetos de software. Os trabalhos de Riel (1996), Fowler(1999) e Lanza e Marinescu (2005) representam uma teoria sobre o tema. Essa teoria éformada por uma ampla discussão sobre heurísticas que direcionam desenvolvedores paraa detecção de anomalias (FOWLER, 1999)

Analysing Wiki Quality using Probabilistic Model Checking

Abstract-Wikis delineate a new work tool in enterprises and they are spreading everywhere. Indeed, they are often used as internal documentation for various in-house systems and applications as well as powerful tools for collaboration and knowledge sharing. As occurs with software, the fundamental growth of a wiki may lead to its degradation. The quality of wikis, especially in enterprise contexts, should not play a trivial role. Software quality is a very discussed topic, but there are not many studies regarding the quality of wikis. We propose a probabilistic model to represent wikis and to investigate their quality. Due to the similarity with the World Wide Web it is natural to consider the popular Google PageRank (with minor modifications) to calculate probabilities between pages. Each wiki category, a set of wiki pages, is modelled using the PRISM language in order to verify specific properties in PCTL*. Experiments conducted on a adequate number of (enterprise) wikis assess the validity of our methodology

Study of Code Smells: A Review and Research Agenda

Code Smells have been detected, predicted and studied by researchers from several perspectives. This literature review is conducted to understand tools and algorithms used to detect and analyze code smells to summarize research agenda. 114 studies have been selected from 2009 to 2022 to conduct this review. The studies are deeply analyzed under the categorization of machine learning and non-machine learning, which are found to be 25 and 89 respectively. The studies are analyzed to gain insight into algorithms, tools and limitations of the techniques. Long Method, Feature Envy, and Duplicate Code are reported to be the most popular smells. 38% of the studies focused their research on the enhancement of tools and methods. Random Forest and JRip algorithms are found to give the best results under machine learning techniques. We extended the previous studies on code smell detection tools, reporting a total 87 tools during the review. Java is found to be the dominant programming language during the study of smells

Do they Really Smell Bad? A Study on Developers’ Perception of Bad Code Smells

In the last decade several catalogues have been defined to characterize bad code smells, i.e., symptoms of poor design and implementation choices. On top of such catalogues, researchers have defined methods and tools to automatically detect and/or remove bad smells. Nevertheless, there is an ongoing debate regarding the extent to which developers perceive bad smells as serious design problems. Indeed, there seems to be a gap between theory and practice, i.e., what is believed to be a problem (theory) and what is actually a problem (practice). This paper presents a study aimed at providing empirical evidence on how developers perceive bad smells. In this study, we showed to developers code entities—belonging to three systems— affected and not by bad smells, and we asked them to indicate whether the code contains a potential design problem, and if any, the nature and severity of the problem. The study involved both original developers from the three projects and outsiders, namely industrial developers and Master’s students. The results provide insights on characteristics of bad smells not yet explored sufficiently. Also, our findings could guide future research on approaches for the detection and removal of bad smells

Automatic Detection of GUI Design Smells: The Case of Blob Listener

International audienceGraphical User Interfaces (GUIs) intensively rely on event-driven programming: widgets send GUI events, which capture users' interactions, to dedicated objects called controllers. Controllers implement several GUI listeners that handle these events to produce GUI commands. In this work, we conducted an empirical study on 13 large Java Swing open-source software systems. We study to what extent the number of GUI commands that a GUI listener can produce has an impact on the change-and fault-proneness of the GUI listener code. We identify a new type of design smell, called Blob listener that characterizes GUI listeners that can produce more than two GUI commands. We show that 21 % of the analyzed GUI controllers are Blob listeners. We propose a systematic static code analysis procedure that searches for Blob listener that we implement in InspectorGuidget. We conducted experiments on six software systems for which we manually identified 37 instances of Blob listener. InspectorGuidget successfully detected 36 Blob listeners out of 37. The results exhibit a precision of 97.37 % and a recall of 97.59 %. Finally, we propose coding practices to avoid the use of Blob listeners

Using Word Embedding and Convolution Neural Network for Bug Triaging by Considering Design Flaws

Resolving bugs in the maintenance phase of software is a complicated task. Bug assignment is one of the main tasks for resolving bugs. Some Bugs cannot be fixed properly without making design decisions and have to be assigned to designers, rather than programmers, to avoid emerging bad smells that may cause subsequent bug reports. Hence, it is important to refer some bugs to the designer to check the possible design flaws. Based on our best knowledge, there are a few works that have considered referring bugs to designers. Hence, this issue is considered in this work. In this paper, a dataset is created, and a CNN-based model is proposed to predict the need for assigning a bug to a designer by learning the peculiarities of bug reports effective in creating bad smells in the code. The features of each bug are extracted from CNN based on its textual features, such as a summary and description. The number of bad samples added to it in the fixing process using the PMD tool determines the bug tag. The summary and description of the new bug are given to the model and the model predicts the need to refer to the designer. The accuracy of 75% (or more) was achieved for datasets with a sufficient number of samples for deep learning-based model training. A model is proposed to predict bug referrals to the designer. The efficiency of the model in predicting referrals to the designer at the time of receiving the bug report was demonstrated by testing the model on 10 projects

RePOR: Mimicking humans on refactoring tasks. Are we there yet?

Refactoring is a maintenance activity that aims to improve design quality while preserving the behavior of a system. Several (semi)automated approaches have been proposed to support developers in this maintenance activity, based on the correction of anti-patterns, which are `poor' solutions to recurring design problems. However, little quantitative evidence exists about the impact of automatically refactored code on program comprehension, and in which context automated refactoring can be as effective as manual refactoring. Leveraging RePOR, an automated refactoring approach based on partial order reduction techniques, we performed an empirical study to investigate whether automated refactoring code structure affects the understandability of systems during comprehension tasks. (1) We surveyed 80 developers, asking them to identify from a set of 20 refactoring changes if they were generated by developers or by a tool, and to rate the refactoring changes according to their design quality; (2) we asked 30 developers to complete code comprehension tasks on 10 systems that were refactored by either a freelancer or an automated refactoring tool. To make comparison fair, for a subset of refactoring actions that introduce new code entities, only synthetic identifiers were presented to practitioners. We measured developers' performance using the NASA task load index for their effort, the time that they spent performing the tasks, and their percentages of correct answers. Our findings, despite current technology limitations, show that it is reasonable to expect a refactoring tools to match developer code

A User Feedback Centric Approach for Detecting and Mitigating God Class Code Smell Using Frequent Usage Patterns

Code smells are the fragments in the source code that indicates deeper problems in the underlying software design. These code smells can hinder software evolution and maintenance. Out of different code smell types, the God Class (GC) code smell is one of the many important code smells that directly affects the software evolution and maintenance. The GC is commonly defined as a much larger class in systems that either know too much or do too much as compared to other classes in the system. God Classes are generally accidentally created overtime during software evolution because of the incremental addition of functionalities to it. Generally, a GC indicates a bad design choice and it must be detected and mitigated in order to enhance the quality of the underlying software. However, sometimes the presence of a GC is also considered a good design choice, especially in compiler design, interpreter design and parser implementation. This makes the developer’s feedback important for the correct classification of a class as a GC or a normal class. Therefore, this paper proposes a new approach that detects and proposes refactoring opportunities for GC code smell. The proposed approach makes use of different code metrics in combination along with utilizing user feedback as an important aspect while correctly identifying the GC code smell. The proposed approach that considers combined use of code metrics, is based on two newly proposed code metrics in this paper. The first newly proposed metric is a new approach of measuring the connectivity of a given class with other classes in the system (also termed as coupling). The second newly proposed code metric is proposed to measure the extent to which a given classes make use of foreign member variables. Finally, the proposed approach is also empirically evaluated on two standard open-source commonly used software systems. The obtained result indicates that the proposed approach is capable of correctly identifying the GC code smell