Source Code Quality Research Articles

Improving Source Code Quality by Minimizing Refactoring Effort

Software maintenance is a time-consuming and costly endeavor. As a part of maintenance, refactoring is aimed at enhancing quality. Due to project deadlines and limited resources, developers need to prioritize refactoring activities. In this paper, we present a livestock management-inspired approach for identifying and prioritizing classes to refactor within an object-oriented program. This approach empowers developers to enhance the time/quality ratio. The novelty of our approach lies in utilizing established metrics for detecting code defects to prioritize each class. To validate its effectiveness, the approach was tested on four distinct Pharo-based open source programs. The results demonstrate the approach's efficacy in improving software quality, reducing development time, and enhancing team productivity

Studying the Quality of Source Code Generated by Different AI Generative Engines: An Empirical Evaluation

The advent of Generative Artificial Intelligence is opening essential questions about whether and when AI will replace human abilities in accomplishing everyday tasks. This issue is particularly true in the domain of software development, where generative AI seems to have strong skills in solving coding problems and generating software source code. In this paper, an empirical evaluation of AI-generated source code is performed: three complex coding problems (selected from the exams for the Java Programming course at the University of Insubria) are prompted to three different Large Language Model (LLM) Engines, and the generated code is evaluated in its correctness and quality by means of human-implemented test suites and quality metrics. The experimentation shows that the three evaluated LLM engines are able to solve the three exams but with the constant supervision of software experts in performing these tasks. Currently, LLM engines need human-expert support to produce running code that is of good quality.

Forward-Oriented Programming: A meta-DSL for fast development of component libraries

Libraries that implement Domain-Specific Language (DSL) components keep gaining traction when it comes to developing software for specific application domains. However, creating components that can be organically weaved into use cases is an extremely complex task. In this work, we introduce a meta-DSL to assist library development, called Forward-Oriented Programming (FOP). This combines lazy evaluation and aspect-oriented programming principles to align crosscutting component configurations and alter their execution outcomes depending on usage in subsequent code. Theoretical analysis shows that FOP simplifies component development and makes their combination logic learnable by library users. We realize the paradigm with a Python package, called pyfop, and conduct a case study that compares it with purely functional and object-oriented library implementations. In the study, source code quality metrics demonstrate reduced time and effort to write library components, and increased comprehensibility. Configurations are shared without modifying distant code segments.

A study of dealing class imbalance problem with machine learning methods for code smell severity detection using PCA-based feature selection technique

Detecting code smells may be highly helpful for reducing maintenance costs and raising source code quality. Code smells facilitate developers or researchers to understand several types of design flaws. Code smells with high severity can cause significant problems for the software and may cause challenges for the system's maintainability. It is quite essential to assess the severity of the code smells detected in software, as it prioritizes refactoring efforts. The class imbalance problem also further enhances the difficulties in code smell severity detection. In this study, four code smell severity datasets (Data class, God class, Feature envy, and Long method) are selected to detect code smell severity. In this work, an effort is made to address the issue of class imbalance, for which, the Synthetic Minority Oversampling Technique (SMOTE) class balancing technique is applied. Each dataset's relevant features are chosen using a feature selection technique based on principal component analysis. The severity of code smells is determined using five machine learning techniques: K-nearest neighbor, Random forest, Decision tree, Multi-layer Perceptron, and Logistic Regression. This study obtained the 0.99 severity accuracy score with the Random forest and Decision tree approach with the Long method code smell. The model's performance is compared based on its accuracy and three other performance measurements (Precision, Recall, and F-measure) to estimate severity classification models. The impact of performance is also compared and presented with and without applying SMOTE. The results obtained in the study are promising and can be beneficial for paving the way for further studies in this area.

Developers talking about code quality

There are many aspects of code quality, some of which are difficult to capture or to measure. Despite the importance of software quality, there is a lack of commonly accepted measures or indicators for code quality that can be linked to quality attributes. We investigate software developers’ perceptions of source code quality and the practices they recommend to achieve these qualities. We analyze data from semi-structured interviews with 34 professional software developers, programming teachers and students from Europe and the U.S. For the interviews, participants were asked to bring code examples to exemplify what they consider good and bad code, respectively. Readability and structure were used most commonly as defining properties for quality code. Together with documentation, they were also suggested as the most common target properties for quality improvement. When discussing actual code, developers focused on structure, comprehensibility and readability as quality properties. When analyzing relationships between properties, the most commonly talked about target property was comprehensibility. Documentation, structure and readability were named most frequently as source properties to achieve good comprehensibility. Some of the most important source code properties contributing to code quality as perceived by developers lack clear definitions and are difficult to capture. More research is therefore necessary to measure the structure, comprehensibility and readability of code in ways that matter for developers and to relate these measures of code structure, comprehensibility and readability to common software quality attributes.

The impact of unequal contributions in student software engineering team projects

Unequal distribution of work is a common problem in student team projects, undermining learning objectives and reducing student satisfaction with teamwork. More is needed to be known about the impact of unequal distribution of work on the performance of student software engineering teams and their members and the relationship between objective measures of unequal contribution and team-perceived unequal contribution. A greater understanding of these issues allows for targeted and personalised responses to these behaviours. We investigated several aspects of unequal contribution in student software engineering teams. We measured inequality of contribution using Git data from student software engineering teams, source code quality using code analyser SonarQube, and the team performance using grades. According to our results, most students under-contributed to their teams, and at least half the teams in each assignment had low equality of contribution or extreme inequality of contribution. Individual contribution styles did not strongly persist between modules (one-semester-long software engineering courses). There were no consistent associations between inequality of contribution in the student teams and performance or code quality. When the contribution of the least active team member was less than 14% of their fair share, teams were likely to perceive an unequal distribution of contributions.

An Exploratory Study on Code Smells during Code Review in OSS Projects: A Case Study on OpenStack and WikiMedia

Objective: Open-source software (OSS) has become an important choice for developing software applications, and its usage has exponentially increased in recent years. Although many OSS systems have shown high reliability in terms of their functionality, they often exhibit several quality issues. Since most developers focus primarily on meeting clients’ functional requirements within the appropriate deadlines, the outcome suffers from poor design and implementation practices. This issue can also manifest as software code smells, resulting in a variety of quality issues such as software maintainability, comprehensibility, and extensibility. Generally speaking, OSS developers use code reviews during their software development to discover flaws or bugs in the updated code before it is merged with the code base. Nevertheless, despite the harmful impacts of code smells on software projects, the extent to which developers do consider them in the code review process is unclear in practice. Methods: To better understand the code review process in OSS projects, we gathered the comments of code reviewers who specified where developers should fix code smells in two OSS projects, OpenStack and WikiMedia, between 2011 and 2015. Results: Our findings indicate that most code reviewers do not pay much attention to code smells. Only a few code reviewers have attempted to motivate developers to improve their source code quality in general. The results also show that there is an increasing tendency to provide advice concerning code smells corrections over time. Conclusion: We believe that this study's findings will encourage developers to use new software engineering practices, such as refactoring, to reduce code smells when developing OSS.

Practical Consequences of Quality Views in Assessing Software Quality

The authors’ previously published research delved into the theory of software product quality modelling, model views, concepts, and terminologies. They also analysed this specific field from the point of view of uncertainty, and possible descriptions based on fuzzy set theory and fuzzy logic. Laying a theoretical foundation was necessary; however, software professionals need a more tangible and practical approach for their everyday work. Consequently, the authors devote this paper to filling in this gap; it aims to illustrate how to interpret and utilise the previous findings, including the established taxonomy of the software product quality models. The developed fuzzy model’s simplification is also presented with a Generalized Additive Model approximation. The paper does not require any formal knowledge of uncertainty computations and reasoning under uncertainty, nor does it need a deep understanding of quality modelling in terms of terminology, concepts, and meta-models, which were necessary to prepare the taxonomy and relevance ranking. The paper investigates how to determine the validity of statements based on a given software product quality model; moreover, it considers how to tailor and adjust quality models to the particular project’s needs. The paper also describes how to apply different software product quality models for different quality views to take advantage of the automation potential offered for the measurement and assessment of source code quality. Furthermore, frequent pitfalls are illustrated with their corresponding resolutions, including an unmeasured quality property that is found to be important and needs to be included in the measurement and assessment process.

Rubbing salt in the wound? A large-scale investigation into the effects of refactoring on security

Software refactoring is a behavior-preserving activity to improve the source code quality without changing its external behavior. Unfortunately, it is often a manual and error-prone task that may induce regressions in the source code. Researchers have provided initial compelling evidence of the relation between refactoring and defects, yet little is known about how much it may impact software security. This paper bridges this knowledge gap by presenting a large-scale empirical investigation into the effects of refactoring on the security profile of applications. We conduct a three-level mining software repository study to establish the impact of 14 refactoring types on (i) security-related metrics, (ii) security technical debt, and (iii) the introduction of known vulnerabilities. The study covers 39 projects and a total amount of 7,708 refactoring commits. The key results show that refactoring has a limited connection to security. However, Inline Method and Extract Interface statistically contribute to improving some security aspects connected to encapsulating security-critical code components. Extract Superclass and Pull Up Attribute refactoring are commonly found in commits violating specific security best practices for writing secure code. Finally, Extract Superclass and Extract & Move Method refactoring tend to occur more often in commits contributing to the introduction of vulnerabilities. We conclude by distilling lessons learned and recommendations for researchers and practitioners.

An Empirical Study on Code Smell Introduction and Removal in Deep Learning Software Projects

With increasing popularity of Deep Learning (DL) software development, code quality issues arise in DL software development. Code smell is one of the factors which reduce the quality of source code. Several previous studies investigated the prevalence of code smell in DL software systems to evaluate the quality of DL source code. However, there is still a lack of understanding of the awareness of individual DL developers in code smell. To more deeply understand the code smell risk in DL software development, it is needed to investigate the code smell awareness of DL developers. In this paper, we present an empirical study on code smell practices of DL developers. Specifically, we performed a quantitative analysis on code smell introduction and removal practices of DL developers. We collected a dataset of code smell introduction and removal history of DL developers from several open source DL software GitHub repositories. We then quantitatively analyzed the collected dataset. As a result of the quantitative analysis, we observed the following three findings on code smell introduction and removal practices of DL developers. First, DL developers tend to perform code smell introduction practice more than code smell removal practice. Second, DL developers have slightly broader code smell introduction scope than code smell removal scope. Third, regular and irregular DL developers have less difference in both code smell introduction and removal practices. The results indicate that DL developers have very poor awareness on code smell risk. Our findings suggest that DL software development project managers should provide a helpful guideline that makes DL developers actively participate code smell removal tasks.

Competencies for Code Review

Peer code review is a widely practiced software engineering process in which software developers collaboratively evaluate and improve source code quality. Whether developers can perform good reviews depends on whether they have sufficient competence and experience. However, the knowledge of what competencies developers need to execute code review is currently limited, thus hindering, for example, the creation of effective support tools and training strategies. To address this gap, we firstly identified 27 competencies relevant to performing code review through expert validation. Later, we conducted an online survey with 105 reviewers to rank these competencies along four dimensions: frequency of usage, importance, proficiency, and desire of reviewers to improve in that competency. The survey shows that technical competencies are considered essential to performing reviews and that respondents feel generally confident in their technical proficiency. Moreover, reviewers feel less confident in how to communicate clearly and give constructive feedback - competencies they consider like-wise an essential part of reviewing. Therefore, research and education should focus in more detail on how to support and develop reviewers' potential to communicate effectively during reviews. In the paper, we also discuss further implications for training, code review performance assessment, and reviewers of different experience level. Data and materials: https://doi.org/10.5281/zenodo.7401313

Requirements on Technical Debt: Dare to Specify Them!

Could maintainability requirements help organizations prioritize technical debt management? The new standard ISO/IEC 5055 Automated Source Code Quality Measures can be used to set targets. We also look at a pragmatic way to turn CodeScene’s code health metric into a quality gate for pull requests.

Impacts of software community patterns on process and product: An empirical study

Software engineering projects are now more than ever a community effort. In the recent past, researchers have shown that their success not only depends on source code quality, but also on other aspects like the balance of power distance, culture, and global engineering practices, and more. In such a scenario, understanding the characteristics of the community around a project and foresee possible problems may be the key to develop successful systems. In this paper, we focus on this research problem and propose an exploratory study on the relation between community patterns, i.e., recurrent mixes of organizational or social structure types, and aspects related to the quality of software products and processes by mining open-source software repositories hosted on GitHub . We first exploit association rule mining to discover frequent relations between community pattern and community smells, i.e., sub-optimal patterns across the organizational structure of a software development community that may be precursors of some form of social debt. Further on, we use statistical analyses to understand their impact on software maintainability and on the community engagement, in terms of contributions and issues. Our findings show that different organizational patterns are connected to different forms of socio-technical problems; further on, specific combinations are set in equally specific contextual conditions. Findings support two possible conclusions: (1) practitioners should put in place specific preventive actions aimed at avoiding the emergence of community smells and (2) such actions should be drawn according to the contextual conditions of the organization and the project. • A list of association rules between community patterns and community smells to see how they relate each other. • An empirical analysis on how community patterns affect the product quality. • An empirical analysis on how community patterns affect the development process. • A replication package containing all the materials to reproduce and extend our study.

The Impact of Peer Code Review on Software Maintainability in Open-Source Software: A Case Study

Recently, open-source software (OSS) has become a considerably popular and reliable source of functionality corrections. OSS also allows software developers to reduce technical debt in software development. However, previous studies have shown that the main problem within OSS development is the lack of systematic processes and formal documents related to system development, such as requirements, designs, and testing. This feature of OSS development causes problems in the software quality, such as those related to security and maintainability. In this research, the authors focused on the software’s maintainability because this attribute has to greatest potential to reduce the cost and increase the productivity of the software development process. There is currently no existing research that examines whether OSS developers pay attention to software maintainability. To better understand how OSS developers improve software maintainability, this research aims to answer the question: “Are developers interested in software maintainability under the modern code review of open-source software projects?” To answer the research question, the authors investigated the code review process in which the OSS developers changed the code based on a review of code comments related to maintenance and collected the sub-characteristics associated with software maintainability from the existing literature. The authors examined the review comments from two OSS projects: Eclipse and Qt. The results suggest that the number of code revisions due to maintenance issues was moderate and that the OSS developers tend to improve source code quality. This direction could be observed from the increasing number of modifications on given maintenance-based comments over the years. Therefore, an implication of this is the possibility that OSS project developers are interested in software maintainability.

Economic effect of software quality evaluation procedure in small IT businesses

IT industry is growing fast from year to year, which leads to growing competition in the respective market. That is why quality evaluation best practices are becoming more widely appreciated. Relevance of the chosen theme results from the fact that appropriate quality evaluation process is required to make a competitive product in the IT industry. The intention of this paper is to suggest a software quality evaluation procedure for small IT businesses. This market segment does not have a formalized basis for comprehensive quality evaluation. The designed procedure includes five steps: describing a software product, selection of key quality measures of the software product and its source code, selection of appropriate methods for measuring, quality evaluation according to the key measures and calculation source code quality metrics, quality rate calculation. The importance of high-quality source code has been demonstrated by a chart which shows a dependency of total implemented functionality from time in two cases: high-quality source code and low-quality source code. As a conclusion, it is claimed that introduction of quality evaluation procedure does not lead to material costs increase, which is highly important for small IT businesses. There is economic effect analysis of introduction of software quality evaluation procedure in small IT businesses.

Why Do Developers Reject Refactorings in Open-Source Projects?

Refactoring operations are behavior-preserving changes aimed at improving source code quality. While refactoring is largely considered a good practice, refactoring proposals in pull requests are often rejected after the code review. Understanding the reasons behind the rejection of refactoring contributions can shed light on how such contributions can be improved, essentially benefiting software quality. This article reports a study in which we manually coded rejection reasons inferred from 330 refactoring-related pull requests from 207 open-source Java projects. We surveyed 267 developers to assess their perceived prevalence of these identified rejection reasons, further complementing the reasons. Our study resulted in a comprehensive taxonomy consisting of 26 refactoring-related rejection reasons and 21 process-related rejection reasons. The taxonomy, accompanied with representative examples and highlighted implications, provides developers with valuable insights on how to ponder and polish their refactoring contributions, and indicates a number of directions researchers can pursue toward better refactoring recommenders.

On the effects of continuous delivery on code quality: A case study in industry

Continuous delivery has been adopted by organizations to make software available to their users at any time. The transition from traditional software delivery methodologies to continuous delivery can impact on the results generated by organizations, e.g., the quality of source code and products. Although widely adopted, little is known about its effects. To account for this, this article reports a case study on the effects of continuous delivery on the quality of source code and products produced. Our case study was carried out for 12 months within a software development company in Brazil. Our findings indicate that the adoption of continuous delivery practices improved the quality of delivered products, mainly considering the number of defects reported by customers, the number of demands delivered per month, and user satisfaction. However, the adoption of continuous delivery did not favor the quality of source code, including the number of bugs, security vulnerabilities, code smells, duplicated code, and code complexity. Researchers and practitioners may benefit from our findings typically when delivering software products, designing and seeking to improve deployment pipeline practices. Finally, our study draws up some implications and shows the potential of adopting continuous delivery for developing enterprise applications that are constantly evolving.

Industry practices and challenges for the evolvability assurance of microservices

ContextMicroservices as a lightweight and decentralized architectural style with fine-grained services promise several beneficial characteristics for sustainable long-term software evolution. Success stories from early adopters like Netflix, Amazon, or Spotify have demonstrated that it is possible to achieve a high degree of flexibility and evolvability with these systems. However, the described advantageous characteristics offer no concrete guidance and little is known about evolvability assurance processes for microservices in industry as well as challenges in this area. Insights into the current state of practice are a very important prerequisite for relevant research in this field.ObjectiveWe therefore wanted to explore how practitioners structure the evolvability assurance processes for microservices, what tools, metrics, and patterns they use, and what challenges they perceive for the evolvability of their systems.MethodWe first conducted 17 semi-structured interviews and discussed 14 different microservice-based systems and their assurance processes with software professionals from 10 companies. Afterwards, we performed a systematic grey literature review (GLR) and used the created interview coding system to analyze 295 practitioner online resources.ResultsThe combined analysis revealed the importance of finding a sensible balance between decentralization and standardization. Guidelines like architectural principles were seen as valuable to ensure a base consistency for evolvability and specialized test automation was a prevalent theme. Source code quality was the primary target for the usage of tools and metrics for our interview participants, while testing tools and productivity metrics were the focus of our GLR resources. In both studies, practitioners did not mention architectural or service-oriented tools and metrics, even though the most crucial challenges like Service Cutting or Microservices Integration were of an architectural nature.ConclusionsPractitioners relied on guidelines, standardization, or patterns like Event-Driven Messaging to partially address some reported evolvability challenges. However, specialized techniques, tools, and metrics are needed to support industry with the continuous evaluation of service granularity and dependencies. Future microservices research in the areas of maintenance, evolution, and technical debt should take our findings and the reported industry sentiments into account.

An empirical study on the co-occurrence between refactoring actions and Self-Admitted Technical Debt removal

Technical Debt (TD) concerns the lack of an adequate solution in a software project, from its design to the source code. Its admittance through source code comments, issues, or commit messages is referred to as Self-Admitted Technical Debt (SATD). Previous research has studied SATD from different perspectives, including its distribution, impact on software quality, and removal. In this paper, we investigate the relationship between refactoring and SATD removal. By leveraging a dataset of SATD and their removals in four open-source projects and by using an automated refactoring detection tool, we study the co-occurrence of refactoring and SATD removals. Results of the study indicate that refactoring is more likely to co-occur with SATD removals than with other commits, however, in most cases, they belong to different quality improvement activities performed at the same time. Moreover, if looking closely at refactoring actions co-occurring with SATD removal in the same code entities, a relationship between these activities can be found. Finally, we found how both source code quality metrics and SATD removals play a statistically significant role in the likelihood that the commit applies a refactoring action.

Software Source Code: Theoretical Analyzing and Practical Reviewing Model

The high-quality software product is one of the most important goals of software engineering in general, source coding or implementation phase is one of the main steps of the software development process; when this phase is going in a good way and according to the source code quality standards and rules, the final product will be a high-quality product. This research focuses on the issues that can affect source code quality, such as errors, faults, defects, and failures; a practical system model will be provided (proposed) to predict some possible types of errors and defects and suggests some guidance and recommendations on source code error detection and analysis.