Code Smells Research Articles

Analysis of The Impact of Software Detailed Design on Mobile Application Performance Metrics

The rapid development of mobile applications in recent years has forced developers to develop their applications quickly. Application quality must be one of the top concerns of developers since poor application design will affect the quality of the application. Performance is one of the important quality attributes that determine the quality of an application. One approach that can be used to overcome performance problems is the design pattern. However, as the research progressed, other approaches were discovered such as refactoring code smells and design principles. In this study, a detailed design analysis was carried out on the source code of the mobile application by applying design patterns, refactoring the code smells, and implementing design principles to determine their impact on the application's performance. To measure the application performance, Central Processing Unit (CPU) usage, memory usage, and frame rate metrics are used. Based on the implementation design patterns, refactoring the code smells, and applying design principles, the result found that design patterns can affect application performance depending on the design pattern used. The Strategy pattern and Visitor pattern optimize memory usage by 1%, while the Bridge pattern increases memory usage by 2%. Meanwhile, the result of refactoring the code smells can optimize CPU usage by 35% and memory usage by 2%, and design principles can optimize CPU usage by 25% and application frame rates by 5 frame per second (fps).

Handling uncertainty in SBSE: a possibilistic evolutionary approach for code smells detection

Handling uncertainty in SBSE: a possibilistic evolutionary approach for code smells detection

An empirical study of data constraint implementations in Java

Software systems are designed according to guidelines and constraints defined by business rules. Some of these constraints define the allowable or required values for data handled by the systems. These data constraints usually originate from the problem domain (e.g., regulations), and developers must write code that enforces them. Understanding how data constraints are implemented is essential for testing, debugging, and software change. Unfortunately, there are no widely-accepted guidelines or best practices on how to implement data constraints. This paper presents an empirical study that investigates how data constraints are implemented in Java. We study the implementation of 187 data constraints extracted from the documentation of eight real-world Java software systems. First, we perform a qualitative analysis of the textual description of data constraints and identify four data constraint types. Second, we manually identify the implementations of these data constraints and reveal that they can be grouped into 31 implementation patterns. The analysis of these implementation patterns indicates that developers prefer a handful of patterns when implementing data constraints. We also found evidence suggesting that deviations from these patterns are associated with unusual implementation decisions or code smells. Third, we develop a tool-assisted protocol that allows us to identify 256 additional trace links for the data constraints implemented using the 13 most common patterns. We find that almost half of these data constraints have multiple enforcing statements, which are code clones of different types. Finally, a study with 16 professional developers indicates that the patterns we describe can be easily and accurately recognized in Java code.

Code Smell Prioritization with Business Process Mining and Static Code Analysis: A Case Study

One of the most significant impediments to the long-term maintainability of software applications is code smells. Keeping up with the best coding practices can be difficult for software developers, which might lead to performance throttling or code maintenance concerns. As a result, it is imperative that large applications be regularly monitored for performance issues and code smells, so that these issues can be corrected promptly. Resolving code smells in software systems can be done in a variety of ways, but doing so all at once would be prohibitively expensive and can be out of budget. Prioritizing these solutions are therefore critical. The majority of current research prioritizes code smells according to the type of smell they cause. This method, however, is not sufficient because of a lack of knowledge regarding the frequency of code usage and code changeability behavior. Even the most complex programs have some components that are more important than others. Maintaining the functionality of certain parts is essential since they are often used. Identifying and correcting code smells in places that are frequently utilized and subject to rapid change should take precedence over other code smells. A novel strategy is proposed for finding frequently used and change-prone areas in a codebase by combining business logic, heat map information, and commit history analysis in this study. It examines the codebase, commits, and log files of Java applications to identify business processes, heat map graphs, and severity levels of various types of code smells and their commit history. This is done in order to present a comprehensive, efficient, and resource-friendly technique for identifying and prioritizing performance throttling with also handling code maintenance concerns.

Law Smells

Building on the computer science concept of code smells, we initiate the study of law smells, i.e., patterns in legal texts that pose threats to the comprehensibility and maintainability of the law. With five intuitive law smells as running examples—namely, duplicated phrase, long element, large reference tree, ambiguous syntax, and natural language obsession—, we develop a comprehensive law smell taxonomy. This taxonomy classifies law smells by when they can be detected, which aspects of law they relate to, and how they can be discovered. We introduce text-based and graph-based methods to identify instances of law smells, confirming their utility in practice using the United States Code as a test case. Our work demonstrates how ideas from software engineering can be leveraged to assess and improve the quality of legal code, thus drawing attention to an understudied area in the intersection of law and computer science and highlighting the potential of computational legal drafting.

Deep convolutional neural network model for bad code smells detection based on oversampling method

Code <span>smells refers to any symptoms or anomalies in the source code that shows violation of design principles or implementation. Early detection of bad code smells improves software quality. Nowadays several artificial neural network (ANN) models have been used for different topics in software engineering: software defect prediction, software vulnerability detection, and code clone detection. It is not necessary to know the source of the data when using ANN models but require large training sets. Data imbalance is the main challenge of artificial intelligence techniques in detecting the code smells. To overcome these challenges, the objective of this study is to presents deep convolutional neural network (D-CNN) model with synthetic minority over-sampling technique (SMOTE) to detect bad code smells based on a set of Java projects. We considered four code-smell datasets which are God class, data class, feature envy and long method and the results were compared based on different performance measures. Experimental results show that the proposed model with oversampling techniques can provide better performance for code smells detection and prediction results can be further improved when the model is trained with more datasets. Moreover, more epochs and hidden layers help increase the accuracy of the model.</span>

Automatic detection of Long Method and God Class code smells through neural source code embeddings

Code smells are structures in code that often harm its quality. Manually detecting code smells is challenging, so researchers proposed many automatic detectors. Traditional code smell detectors employ metric-based heuristics, but researchers have recently adopted a Machine-Learning (ML) based approach. This paper compares the performance of multiple ML-based code smell detection models against multiple metric-based heuristics for detection of God Class and Long Method code smells. We assess the effectiveness of different source code representations for ML: we evaluate the effectiveness of traditionally used code metrics against code embeddings (code2vec, code2seq, and CuBERT). This study is the first to evaluate the effectiveness of pre-trained neural source code embeddings for code smell detection to the best of our knowledge. This approach helped us leverage the power of transfer learning – our study is the first to explore whether the knowledge mined from code understanding models can be transferred to code smell detection. A secondary contribution of our research is the systematic evaluation of the effectiveness of code smell detection approaches on the same large-scale, manually labeled MLCQ dataset. Almost every study that proposes a detection approach tests this approach on the dataset unique for the study. Consequently, we cannot directly compare the reported performances to derive the best-performing approach.

SSHM: SMOTE-stacked hybrid model for improving severity classification of code smell

SSHM: SMOTE-stacked hybrid model for improving severity classification of code smell

Search based Software Engineering of Software Metrics, Code Smells and Refactoring Techniques Using Optimization Algorithms

Software refactoring is a technique for reorganising and improving the efficiency of existing software code. By refining the non-functional aspects of software, numerous refactoring methods are currently being employed to build more intelligible and less composite codes. By applying multiple systems to the source code, refactoring can improve code maintainability even further, preserving the behaviour of the code. Refactoring allows for the eradication of bugs and the expansion of the program's capabilities. This paper provides a comprehensive assessment of source code with foul odours, the influence on software quality of using certain refactoring methodologies to eradicate the foul smell. Between 2008 and 2010, a total of 76 studies from 42 journals, 20 conferences, and 14 additional sources in the year 2008 and 2022 were available. This study was graded on the number of unpleasant odours identified, refactoring strategies applied, and their impact on software metrics. The foul smells of "method of long," "envious feature “and” class of data" were discovered or corrected in the majority of inquiries. The odour of "envious feature" was detected in 39.66 per cent of nominated investigations. The majority of studies looked at the effects of restructuring on software intricacy and coupling measures. Surprisingly, instead of patented software, the majority of the investigations employed massive opensource datasets released in Java. Finally, this research makes suggestions for further into the refactoring research code.

HBSniff: A static analysis tool for Java Hibernate object-relational mapping code smell detection

Code smells are symptoms of sub-optimal software design and implementation choices. Detection tools were actively developed for general code smell related to coupling and cohesion issues, but such tools cannot capture domain-specific problems. In this work, we fill the gap in data persistence and query code quality by proposing HBSniff, i.e., a static analysis tool for detecting 14 code smells as well as 4 mapping metrics in Java Hibernate Object-Relational Mapping (ORM) codes. HBSniff is tested, documented, and manually validated. It also generates readable and customizable reports for every project. Moreover, it is beneficial to Mining Software Repository (MSR) research requiring large-scale analysis since project compilation is not needed for detection.

Does CAD Smell Like Code? A Mapping Between Violation of Object Oriented Programming Design Principles and Computer Aided Design Modelling

AbstractIn objected-oriented design, "smells" are symptoms of code violating design principles. When a deadline is looming, decisions can affect the long-term quality of a code or CAD. Given this and the similarities between object-oriented code and CAD models, this paper introduces a set of CAD smells. These smells are derived from a top-down review of potential CAD smells mapped against the reported code smells that violate abstraction, modularity, encapsulation, and hierarchy principles. This list was further reviewed considering CAD systems and specific examples (some illustrated in the paper).

Severity classification of software code smells using machine learning techniques: A comparative study

AbstractCode smell is a software characteristic that indicates bad symptoms in code design which causes problems related to software quality. The severity of code smells must be measured because it will help the developers when determining the priority of refactoring efforts. Recently, several studies focused on the prediction of design patterns errors using different detection tools. Nowadays, there is a lack of empirical studies regarding how to measure severity of code smells and which learning model is best to detect the severity of code smells. To overcome such gap, this paper focuses on measuring the severity classification of code smells depending on several machine learning models such as regression models, multinominal models, and ordinal classification models. The Local Interpretable Model Agnostic Explanations (LIME) algorithm was further used to explain the machine learning model's predictions and interpretability. On the other side, we extract the prediction rules generated by the Projective Adaptive Resonance Theory (PART) algorithm in order to study the effectiveness of using software metrics to predict code smells. The results of the experiments have shown that the accuracy of severity classification model is enhanced than baseline and ranking correlation between the predicted and actual model reaches 0.92–0.97 by using Spearman's correlation measure.

How far are we from reproducible research on code smell detection? A systematic literature review

Code smells are symptoms of wrong design decisions or coding shortcuts that may increase defect rate and decrease maintainability. Research on code smells is accelerating, focusing on code smell detection and using code smells as defect predictors. Recent research shows that even between software developers, agreement on what constitutes a code smell is low, but several publications claim the high performance of detection algorithms—which seems counterintuitive, considering that algorithms should be taught on data labeled by developers. This paper aims to investigate the possible reasons for the inconsistencies between studies in the performance of applied machine learning algorithms compared to developers. It focuses on the reproducibility of existing studies. A systematic literature review was performed among conference and journal articles published between 1999 and 2020 to assess the state of reproducibility of the research performed in those papers. A quasi-gold standard procedure was used to validate the search. Modeling process descriptions, reproduction scripts, data sets, and techniques used for their creation were analyzed. We obtained data from 46 publications. 22 of them contained a detailed description of the modeling process, 17 included any reproduction data (data set, results, or scripts) and 15 used existing data sets. In most of the publications, analyzed projects were hand-picked by the researchers. Most studies do not include any form of an online reproduction package, although this has started to change recently—8% of analyzed studies published before 2018 included a full reproduction package, compared to 22% in years 2018–2019. Ones that do include a package usually use a research group website or even a personal one. Dedicated archives are still rarely used for data packages. We recommend that researchers include complete reproduction packages for their studies and use well-established research data archives instead of their own websites. • Full reproduction package was included in 22% of the studies in 2018–2019 • Model description was inadequate in 28% of studies before 2018 and 43% in 2018–2019 • 33% of reviewed studies use an existing data set (most common strategy) • Custom data set creation is usually informal. Criteria are usually vague

Improving Software Design by Mitigating Code Smells

Improving design is a key research challenge during software maintenance. It aims at identifying and mitigating structural characteristics that may cause future problems (code smells). The existing approaches lack in considering the developer’s expertise and penalty consideration during inheritance usage. Therefore, this paper targets identifying three key code smells viz refused bequest, shotgun surgery, and duplicated code. The refused bequest detection approach is based on probabilistic penalized inheritance usage and domain closeness among methods. The shotgun surgery is detected using combined use of co-change and usage pattern based functional relations. Finally, the duplicated code is based on the abstract tree representation and identification of longest common subsequence between the inorder/ postorder traversals. The experimental results uphold the feasibility of the proposed approach.

Crowdsmelling: A preliminary study on using collective knowledge in code smells detection

Code smells are seen as major source of technical debt and, as such, should be detected and removed. However, researchers argue that the subjectiveness of the code smells detection process is a major hindrance to mitigate the problem of smells-infected code. We proposed the crowdsmelling approach based on supervised machine learning techniques, where the wisdom of the crowd (of software developers) is used to collectively calibrate code smells detection algorithms, thereby lessening the subjectivity issue. This paper presents the results of a validation experiment for the crowdsmelling approach. In the context of three consecutive years of a Software Engineering course, a total "crowd" of around a hundred teams, with an average of three members each, classified the presence of 3 code smells (Long Method, God Class, and Feature Envy) in Java source code. These classifications were the basis of the oracles used for training six machine learning algorithms. Over one hundred models were generated and evaluated to determine which machine learning algorithms had the best performance in detecting each of the aforementioned code smells. Good performances were obtained for God Class detection (ROC=0.896 for Naive Bayes) and Long Method detection (ROC=0.870 for AdaBoostM1), but much lower for Feature Envy (ROC=0.570 for Random Forrest). Obtained results suggest that crowdsmelling is a feasible approach for the detection of code smells, but further validation experiments are required to cover more code smells and to increase external validity.

On the adequacy of static analysis warnings with respect to code smell prediction

Code smells are poor implementation choices that developers apply while evolving source code and that affect program maintainability. Multiple automated code smell detectors have been proposed: while most of them relied on heuristics applied over software metrics, a recent trend concerns the definition of machine learning techniques. However, machine learning-based code smell detectors still suffer from low accuracy: one of the causes is the lack of adequate features to feed machine learners. In this paper, we face this issue by investigating the role of static analysis warnings generated by three state-of-the-art tools to be used as features of machine learning models for the detection of seven code smell types. We conduct a three-step study in which we (1) verify the relation between static analysis warnings and code smells and the potential predictive power of these warnings; (2) build code smell prediction models exploiting and combining the most relevant features coming from the first analysis; (3) compare and combine the performance of the best code smell prediction model with the one achieved by a state of the art approach. The results reveal the low performance of the models exploiting static analysis warnings alone, while we observe significant improvements when combining the warnings with additional code metrics. Nonetheless, we still find that the best model does not perform better than a random model, hence leaving open the challenges related to the definition of ad-hoc features for code smell prediction.

Exploring the relationship between refactoring and code debt indicators

AbstractRefactoring, which aims to improve the internal structure of the software systems preserving their behavior, is the most common payment strategy for technical debt (TD) by removing the code smells. There exist many studies presenting code smell detection approaches/tools or investigating their impact on quality attributes. There are also studies that focus on refactoring techniques, their relation with quality attributes, tool supports, and opportunities for them. Although there are several studies addressing the gap between refactoring and TD indicators, the empirical evidence provided is still limited. In this study, we examine the distribution of 29 refactoring types among the different projects and their relation with code smells or faults. We explore the refactoring types that are most commonly performed together and other activities performed with refactorings. We conduct a large exploratory study with automatically detected 57,528 refactorings, 37,553 smells, 27,340 faults, and 134,812 commits of 33 Java projects. Results show that some refactoring types are more commonly applied by developers. Our analysis indicates that refactorings usually remove or do not affect the code smells, and this contradicts with the previous studies. Also, the commits in which refactoring(s) is performed are three times more fault inducing than those without refactoring.

ANN Modelling on Vulnerabilities Detection in Code Smells-Associated Android Applications

Abstract There has been a lot of software design concerns in recent years that come under the code smell. Android Applications Developments experiences more security issues related to code smells that lead to vulnerabilities in software. This research focuses on the vulnerability detection in Android applications which consists of code smells. A multi-layer perceptron-based ANN model is generated for detection of software vulnerabilities and has a precision value of 74.7% and 79.6% accuracy with 2 hidden layers. The focus is laid on 1390 Android classes and involves association mining of the software vulnerabilities with android code smells using APRIORI algorithm. The generated ANN model The findings represent that Member Ignoring Method (MIM) code smell shows an association with Bean Member Serialization (BMS) vulnerability having 86% confidence level and 0.48 support value. An algorithm has also been proposed that would help developers in detecting software vulnerability in the smelly source code of an android applications at early stages of development.

An automated extract method refactoring approach to correct the long method code smell

Long Method is amongst the most common code smells in software systems. Despite various attempts to detect the long method code smell, few automated approaches are presented to refactor this smell. Extract Method refactoring is mainly applied to eliminate the Long Method smell. However, current approaches still face serious problems such as insufficient accuracy in detecting refactoring opportunities, limitations on correction types, the need for human intervention in the refactoring process, and lack of attention to object-oriented principles, mainly single responsibility and cohesion–coupling principles. This paper aims to automatically identify and refactor the long method smells in Java codes using advanced graph analysis techniques, addressing the aforementioned difficulties. First, a graph representing project entities is created. Then, long method smells are detected, considering the methods’ dependencies and sizes. All possible refactorings are then extracted and ranked by a modularity metric, emphasizing high cohesion and low coupling classes for the detected methods. Finally, a proper name is assigned to the extracted method based on its responsibility. Subsequently, the best destination class is determined such that design modularity is maximized. Experts’ opinion is used to evaluate the proposed approach on five different Java projects. The results show the applicability of the proposed method in establishing the single responsibility principle with a 21% improvement compared to the state-of-the-art extract method refactoring approaches.

Further investigation of the survivability of code technical debt items

AbstractContext: Technical debt (TD) discusses the negative impact of sub‐optimal decisions to cope with the need‐for‐speed in software development. Code technical debt items (TDI) are atomic elements of TD that can be observed in code artifacts. Empirical results on open‐source systems demonstrated how code‐smells, which are just one type of TDIs, are introduced and “survive” during release cycles. However, little is known about whether the results on the survivability of code‐smells hold for other types of code TDIs (i.e., bugs and vulnerabilities) and in industrial settings. Goal: Understanding the survivability of code TDIs by conducting an empirical study analyzing two industrial cases and 31 open‐source systems from Apache Foundation. Method: We analyzed 133,670 code TDIs (35,703 from the industrial systems) detected by SonarQube (in 193,196 commits) to assess their survivability using survivability models. Results: In general, code TDIs tend to remain and linger for long periods in open‐source systems, whereas they are removed faster in industrial systems. Code TDIs that survive over a certain threshold tend to remain much longer, which confirms previous results. Our results also suggest that bugs tend to be removed faster, while code smells and vulnerabilities tend to survive longer.