Code Smells Research Articles

Software Code Bloats and Security Identification Model Based on Mikado Methodology: a Refactoring Practice

The term “code smell” or “bad smell” refers to a code that has been written incorrectly and reflects severe defects in software design. Some code smells cause, particularly, security vulnerabilities in software codes. Until now, identification of these codes is mainly done through software tools and not by process methods or models. Based on the Mikado methodology, this paper proposes a model that uses a syntax-metric parser engine to detect insecure software code bloats and security vulnerabilities. This model, named Touba, assesses and analyzes the discovered cases and provides an interactive method for code review and statistical analysis. Employing the proposed model in testing the Juliet Test Suites shows its outstanding performance in terms of the selected measures of precision, recall, and F-measure. The obtained results show that the proposed model has a better performance - compared to the existing tools - in terms of accuracy by 20.3%, recall by 16.76%, and F-measure by 18.61% on average. These results indicate the effectiveness of the proposed - security vulnerability identification - model as the main contribution of this investigation.

Correlating propensity between code smells and vulnerabilities in java applications

correlating propensity between code smells and vulnerabilities in java applications

Research Trends, Detection Methods, Practices, and Challenges in Code Smell: SLR

Research Trends, Detection Methods, Practices, and Challenges in Code Smell: SLR

КОМБІНОВАНІ ПІДХОДИ ДО СТАТИЧНОГО АНАЛІЗУ КОДУ З ВИКОРИСТАННЯМ НЕЙРОННИХ МЕРЕЖ

This article presents an overview of possible approaches to the application of neural networks in the process of static code analysis. It explores the current state of affairs in existing approaches to improving program analysis using machine learning methods, including postprocessing of static analysis alerts, preprocessing of source code, or direct use of machine learning for analyzing source code. Additionally, the article examines the main directions for applying approaches from each category. Both classical approaches and machine learning methods in program analysis possess distinct strengths and weaknesses that should be considered when implementing them in practice. One of the main theses of this research is that understanding the capabilities of combining these approaches, leveraging the flexibility offered by neural networks while maintaining a sufficient level of reliability provided by classical algorithms, is crucial for building a high-quality system. This article covers the following three basic directions of the application of neural networks for the static source code analysis. The first direction is a specification tuning: a refinement of specifications produced by a ‘classic’ static code analyzer (a removal, clustering, ranking of warnings or just assistance in manual warning analysis, etc.). The second direction is a specification inference, to find specifications hidden in code (feature extraction, selection, or code transformation retaining its behaviour, e.g. to make it more suitable for the ‘classic’ static analysis tools). The third way is a black box analysis to discover and fix code defects (syntactic, semantic ones or vulnerabilities), to assist in manual code checking, to format the code automatically or to find code smells (in this direction only a machine learning model is used, its training is performed on the source code directly). The article outlines directions for the future research which will focus on the development and combining of the approaches covered here.

On the Assessment of Interactive Detection of Code Smells in Practice: A Controlled Experiment

On the Assessment of Interactive Detection of Code Smells in Practice: A Controlled Experiment

An Ontology-Based Approach to Reduce the Negative Impact of Code Smells in Software Development Projects

An Ontology-Based Approach to Reduce the Negative Impact of Code Smells in Software Development Projects

Metric-based rule optimizing system for code smell detection using Salp Swarm and Cockroach Swarm algorithm

Software developers find it difficult to select the specific detection rules for different smell types. A set of metrics, thresholds and labels constitutes a code smells detection rule. The generated rules must be optimized efficiently to ensure successful rule selection. The objective is to identify how rules are generated from the labeled data set and selected using bio-inspired algorithms. The goals are met by employing the C4.5 and RIPPER algorithms to generate rules then, optimized using two bio-inspired algorithms, the Salp Swarm Algorithm (SSA) and Cockroach Swarm Optimization (CSO). The optimized sets of rules are evaluated using the similarity metrics which are computed with the help of expected and the detected code smells. The common rule subsets from SSA and CSO are merged to produce the optimal rule subset which can be used for code smell detection. The proposed work has been experimented on Xerces-J, Log4J, Gantt Project and JFreeChart dataset. The work detected code smells with an accuracy of 91.7% for Xerces-J, 96.7% for JFreeChart, 88.6% for Gantt Project and 98% for Log4J. The findings will be useful for both theory and research since the proposed framework allows focusing on rule selection.

Hybrid Model with Multi-Level Code Representation for Multi-Label Code Smell Detection (077)

Code smell is an indicator of potential problems in a software design that have a negative impact on readability and maintainability. Hence, detecting code smells in a timely and effective manner can provide guides for developers in refactoring. Fortunately, many approaches like metric-based, heuristic-based, machine-learning-based and deep-learning-based have been proposed to detect code smells. However, existing methods, using the simple code representation to describe different code smells unilaterally, cannot efficiently extract enough rich information from source code. In addition, one code snippet often has several code smells at the same time and there is a lack of multi-label code smell detection based on deep learning. In this paper, we present a large-scale dataset for the multi-label code smell detection task since there is still no publicly sufficient dataset for this task. The release of this dataset would push forward the research in this field. Based on it, we propose a hybrid model with multi-level code representation to further optimize the code smell detection. First, we parse the code into the abstract syntax tree (AST) with control and data flow edges and the graph convolution network is applied to get the prediction at the syntactic and semantic level. Then we use the bidirectional long-short term memory network with attention mechanism to analyze the code tokens at the token-level in the meanwhile. Finally, we get the fusion prediction result of the models. Experimental results illustrate that our proposed model outperforms the state-of-the-art methods not only in single code smell detection but also in multi-label code smell detection.

Code Smell Detection Using Ensemble Machine Learning Algorithms

Code smells are the result of not following software engineering principles during software development, especially in the design and coding phase. It leads to low maintainability. To evaluate the quality of software and its maintainability, code smell detection can be helpful. Many machine learning algorithms are being used to detect code smells. In this study, we applied five ensemble machine learning and two deep learning algorithms to detect code smells. Four code smell datasets were analyzed: the Data class, the God class, the Feature-envy, and the Long-method datasets. In previous works, machine learning and stacking ensemble learning algorithms were applied to this dataset and the results found were acceptable, but there is scope of improvement. A class balancing technique (SMOTE) was applied to handle the class imbalance problem in the datasets. The Chi-square feature extraction technique was applied to select the more relevant features in each dataset. All five algorithms obtained the highest accuracy—100% for the Long-method dataset with the different selected sets of metrics, and the poorest accuracy, 91.45%, was achieved by the Max voting method for the Feature-envy dataset for the selected twelve sets of metrics.

A machine and deep learning analysis among SonarQube rules, product, and process metrics for fault prediction

BackgroundDevelopers spend more time fixing bugs refactoring the code to increase the maintainability than developing new features. Researchers investigated the code quality impact on fault-proneness, focusing on code smells and code metrics.ObjectiveWe aim at advancing fault-inducing commit prediction using different variables, such as SonarQube rules, product, process metrics, and adopting different techniques.MethodWe designed and conducted an empirical study among 29 Java projects analyzed with SonarQube and SZZ algorithm to identify fault-inducing and fault-fixing commits, computing different product and process metrics. Moreover, we investigated fault-proneness using different Machine and Deep Learning models.ResultsWe analyzed 58,125 commits containing 33,865 faults and infected by more than 174 SonarQube rules violated 1.8M times, on which 48 software product and process metrics were calculated. Results clearly identified a set of features that provided a highly accurate fault prediction (more than 95% AUC). Regarding the performance of the classifiers, Deep Learning provided a higher accuracy compared with Machine Learning models.ConclusionFuture works might investigate whether other static analysis tools, such as FindBugs or Checkstyle, can provide similar or different results. Moreover, researchers might consider the adoption of time series analysis and anomaly detection techniques.

Enhancing Software maintainability and Software quality by detecting and combating Code Smells in Object Oriented Programming

Enhancing Software maintainability and Software quality by detecting and combating Code Smells in Object Oriented Programming

A probabilistic-based approach for automatic identification and refactoring of software code smells

Programmers strive to design programs that are flexible, updateable, and maintainable. However, several factors such as lack of time, high costs, and workload lead to the creation of software with inadequacies known as anti-patterns. To identify and refactor software anti-patterns, many research studies have been conducted using machine learning. Even though some of the previous works were very accurate in identifying anti-patterns, a method that takes into account the relationships between different structures is still needed. Furthermore, a practical method is needed that is trained according to the characteristics of each program. This method should be able to identify anti-patterns and perform the necessary refactorings. This paper proposes a framework based on probabilistic graphical models for identifying and refactoring anti-patterns. A graphical model is created by extracting the class properties from the source code. As a final step, a Bayesian network is trained, which determines whether anti-patterns are present or not based on the characteristics of neighboring classes. To evaluate the proposed approach, the model is trained on six different anti-patterns and six different Java programs. The proposed model has identified these anti-patterns with a mean accuracy of 85.16 percent and a mean recall of 79%. Additionally, this model has been used to introduce several methods for refactoring, and it has been shown that these refactoring methods will ultimately create a system with less coupling and higher cohesion.

An empirical study of Android behavioural code smells detection

An empirical study of Android behavioural code smells detection

Uncertainty-wise software anti-patterns detection: A possibilistic evolutionary machine learning approach

Context:Code smells (a.k.a. anti-patterns) are manifestations of poor design solutions that can deteriorate software maintainability and evolution. Research gap:Existing works did not take into account the issue of uncertain class labels, which is an important inherent characteristic of the smells detection problem. More precisely, two human experts may have different degrees of uncertainty about the smelliness of a particular software class not only for the smell detection task but also for the smell type identification one. Unluckily, existing approaches usually reject and/or ignore uncertain data that correspond to software classes (i.e. dataset instances) with uncertain labels. Throwing away and/or disregarding the uncertainty factor could considerably degrade the detection/identification process effectiveness. From a solution approach viewpoint, there is no work in the literature that proposed a method that is able to detect and/or identify code smells while preserving the uncertainty aspect. Objective:The main goal of our research work is to handle the uncertainty factor, issued from human experts, in detecting and/or identifying code smells by proposing an evolutionary approach that is able to deal with anti-patterns classification with uncertain labels. Method:We suggest Bi-ADIPOK, as an effective search-based tool that is capable to tackle the previously mentioned challenge for both detection and identification cases. The proposed method corresponds to an EA (Evolutionary Algorithm) that optimizes a set of detectors encoded as PK-NNs (Possibilistic K-nearest neighbors) based on a bi-level hierarchy, in which the upper level role consists on finding the optimal PK-NNs parameters, while the lower level one is to generate the PK-NNs. A newly fitness function has been proposed fitness function PomAURPC-OVA_dist (Possibilistic modified Area Under Recall Precision Curve One-Versus-All_distance, abbreviated PAURPC_d in this paper). Bi-ADIPOK is able to deal with label uncertainty using some concepts stemming from the Possibility Theory. Furthermore, the PomAURPC-OVA_dist is capable to process the uncertainty issue even with imbalanced data. We notice that Bi-ADIPOK is first built and then validated using a possibilistic base of smell examples that simulates and mimics the subjectivity of software engineers opinions. Results:The statistical analysis of the obtained results on a set of comparative experiments with respect to four relevant state-of-the-art methods shows the merits of our proposal. The obtained detection results demonstrate that, for the uncertain environment, the PomAURPC-OVA_dist of Bi-ADIPOK ranges between 0.902 and 0.932 and its IAC lies between 0.9108 and 0.9407, while for the certain environment, the PomAURPC-OVA_dist lies between 0.928 and 0.955 and the IAC ranges between 0.9477 and 0.9622. Similarly, the identification results, for the uncertain environment, indicate that the PomAURPC-OVA_dist of Bi-ADIPOK varies between 0.8576 and 0.9273 and its IAC is between 0.8693 and 0.9318. For the certain environment, the PomAURPC-OVA_dist lies between 0.8613 and 0.9351 and the IAC values are between 0.8672 and 0.9476. With uncertain data, Bi-ADIPOK can find 35% more code smells than the second best approach (i.e., BLOP). Furthermore, Bi-ADIPOK has succeeded to reduce the number of false alarms (i.e., misclassified smelly instances) by 12%. In addition, our proposed approach can identify 43% more smell types than BLOP and reduces the number of false alarms by 32%. The same results have been obtained for the certain environment, demonstrating Bi-ADIPOK’s ability to deal with such environment.

Class Change Prediction by Incorporating Community Smell: An Empirical Study

To adapt to changing software requirements, developers need to maintain and modify software through code changes. Predicting change-prone code can help developers to reduce the cost of software maintenance in advance. Prior work confirmed code smell intensity is a reliable metric for predicting change-prone classes. Community smell is a derivation of the concept of code smell in open-source software development community, it refers to poor communication and collaboration problems among developers. We add community smell to existing change prediction models, and propose a software class change prediction model integrating process metrics, code smell intensity metrics, anti-pattern metrics and community smell metrics, which takes into account the technicality and organizational aspects of software development. Experimental results demonstrate that when Multilayer Perceptron is used to build a change prediction model, community smell improves the baseline model by 4.4% and 31.5% in terms of [Formula: see text]-Measure and Recall. In addition, community smell improves baseline model performance to a greater extent in terms of Recall and Precision than code smell-related information.

DeleSmell: Code smell detection based on deep learning and latent semantic analysis

The presence of code smells will increase the risk of failure, make software difficult to maintain, and introduce potential technique debt in the future. Although many deep-learning-based approaches have been proposed to detect code smells, most existing works suffer from the problem of incomplete feature extraction and unbalanced distribution between positive samples and negative samples. Furthermore, the accuracy of existing works can be further improved. This paper proposes a novel approach named DeleSmell to detect code smells based on a deep learning model. The dataset is built by extracting samples from 24 real-world projects. To improve the imbalance in the dataset, a refactoring tool is developed to automatically transform good source code into smelly code and to generate positive samples based on real cases. DeleSmell collects both structural features through iPlasma and semantic features via latent semantic analysis and word2vec. DeleSmell’s model includes a convolutional neural network(CNN) branch and gate recurrent unit(GRU)-attention branch. The final classification is conducted by an support vector machine(SVM). In the experimentation, the effectiveness of DeleSmell is evaluated by answering seven research questions. The experimental results show that DeleSmell improves the accuracy of brain class (BC) and brain method (BM) code smells detection by up to 4.41% compared with existing approaches, demonstrating the effectiveness of our approach.

Antipattern Practice for Essence Practice Library

The Essence graphical representation language allows to describe various project management practices in software development. At the moment, the Practice Library describes the most popular development methodologies, but work with various risks, such as code smells or antipatterns, which may be cause of future problems, is not represented. This article presents an extension for the Practice Library of the Essence language in the form of a practice for working with antipatterns. To represent antipatterns in the system, the Antipattern subalpha, its states and checkpoints are proposed. Antipatterns states and checkpoints: 1. Detected: о Signs of poor-quality design or implementation of the Software System have been found. о The boundaries of the low-quality area in the Software System have been defined. о Work Products associated with the inferior part of the Software System have been defined. 2. Identified: о The Software System Elements included in the Antipattern have been determined. о The type of antipattern has been determined. о Dependencies of the Software System on the antipattern elements have been determined. о The impact of the antipattern on the Software System has been estimated. 3. Refactoring Method Defined: о Possible options for refactoring have been identified. о The cost of the refactoring options has been assessed. о The most suitable refactoring method has been selected. 4. Fixed: о The Software System elements included in the antipattern are completely covered by tests. о The antipattern has been refactored. о Tests confirm that the Software System remains operational. о The Work Products related to the changed part of the Software System have been updated. 5. Closed: о Tests, reviews or other appropriate activities have been undertaken to ensure that the antipattern has been corrected or shown not to actually be a fault or flaw. о The antipattern management has been finalized. о Technical debt has decreased. To record data about an antipattern, the work product Antipattern Report and its levels of details with checkpoints are proposed. Levels of details and checkpoints are: 1. Antipattern detected: о The components of the Software System included in the antipattern are defined. 2. Antipatterns properties are determined: о An antipattern type has been defined. 3. Antipattern influence determined: о The cost of antipattern fixing was estimated. о An assessment of possible losses associated with the presence of an antipattern was carried out. о The antipattern is recognized as mandatory for elimination. 4. Antipattern eliminated — optional: о Refactoring completed. о Testing showed the correct work of the components included in the antipattern. о Antipattern elimination activity completed. To analyze the architecture of the system, the Inspect Architecture activity is proposed. The Fix Architecture activity represents actions to fix architecture flaws. Code analysis is presented as a Review the Code activity, and correction of deficiencies found during the analysis is presented as a Refactor the Code activity. The influence of subalpha on the state of the Software System alpha is analyzed. Recommendations were given on the proposed activities. Information about activities is presented in the form of diagrams in the Essence language. The proposed practice allows to record information about the found flaws in the code, process them correctly and avoid problems with the project in the future. It is an example of working with entities that negatively affect the progress of the project.

Exploring Design smells for smell-based defect prediction

Defect prediction is commonly used to reduce the effort from the testing phase of software development. A promising strategy is to use machine learning techniques to predict which software components may be defective. Features are key factors to the prediction’s success, and thus extracting significant features can improve the model’s accuracy. In particular, code smells are a category of those features that have been shown to improve the prediction performance significantly. However, Design code smells, a state-of-the-art collection of code smells based on the violations of the object-oriented programming principles, have not been studied in the context of defect prediction. In this paper, we study the performance of defect prediction models by training multiple classifiers for 97 real projects. We compare using Design code smells as features and using other Traditional smells from the literature and both. Moreover, we cluster and analyze the models’ performance based on the categories of Design code smells. We conclude that the models trained with both the Design code smells and the smells from the literature performed the best, with an improvement of 4.1% for the AUC score, compared to models trained with only Traditional smells. Consequently, Design smells are a good addition to the smells commonly studied in the literature for defect prediction.

Building empirical knowledge on the relationship between code smells and design patterns: An exploratory study

AbstractCode smell is a concept describing potential problems in software design. In opposition, design pattern describes good design solutions in terms of maintainability and reusability. Code smell and design pattern might be perceived as metaphors supporting software design activity in terms of understanding and communication. However, empirical evaluation is needed to investigate their effect in terms of programming activity. Our objective is to build empirical knowledge on the relationship between code smells and design patterns. We carried out an exploratory study based on mining software repositories and in a baseline study addressing software evolution. In total, we analyzed 61 software. Their classes were identified as linked to both code smells and design patterns metaphors. Then, we analyzed the co‐occurrence of these metaphors. Our findings indicate that the relationship between smells and design patterns is software dependent. Some software present many smells linked to design patterns while for other software, smelly classes are not linked to design patterns. We also found that the instability metric weakly reflects this idea. Our study supports better understanding of the topic. It presents results in the opposite direction of expectations that the presence of smells is correlated with the absence of design patterns and vice versa.

Code smells detection via modern code review: a study of the OpenStack and Qt communities

Code review plays an important role in software quality control. A typical review process involves a careful check of a piece of code in an attempt to detect and locate defects and other quality issues/violations. One type of issue that may impact the quality of software is code smells - i.e., bad coding practices that may lead to defects or maintenance issues. Yet, little is known about the extent to which code smells are identified during modern code review. To investigate the concept behind code smells identified in modern code review and what actions reviewers suggest and developers take in response to the identified smells, we conducted an empirical study of code smells in code reviews by analysing reviews from four, large open source projects from the OpenStack (Nova and Neutron) and Qt (Qt Base and Qt Creator) communities. We manually checked a total of 25,415 code review comments obtained by keywords search and random selection; this resulted in the identification of 1,539 smell-related reviews which then allowed the study of the causes of code smells, actions taken against identified smells, time taken to fix identified smells and reasons why developers ignored fixing identified smells. Our analysis found that 1) code smells were not commonly identified in code reviews, 2) smells were usually caused by violation of coding conventions, 3) reviewers usually provided constructive feedback, including fixing (refactoring) recommendations to help developers remove smells, 4) developers generally followed those recommendations and actioned the changes, 5) once identified by reviewers, it usually takes developers less than one week to fix the smells and 6) the main reason why developers chose to ignore the identified smells is that it is not worth fixing the smell. Our results suggest the following: 1) developers should closely follow coding conventions in their projects to avoid introducing code smells, 2) review-based detection of code smells is perceived to be a trustworthy approach by developers, mainly because reviews are context-sensitive (as reviewers are more aware of the context of the code given that they are part of the project’s development team) and 3) program context needs to be fully considered in order to make a decision of whether to fix the identified code smell immediately.