Assessing the Bug-Proneness of Refactored Code: A Longitudinal Multi-Project Study

• URL: http://arxiv.org/abs/2505.08005v1
• Date: Mon, 12 May 2025 19:12:30 GMT
• Title: Assessing the Bug-Proneness of Refactored Code: A Longitudinal Multi-Project Study
• Authors: Isabella Ferreira, Lawrence Arkoh, Anderson Uchôa, Ana Carla Bibiano, Alessandro Garcia, Wesley K. G. Assunção,
• Abstract summary: Refactoring is a common practice in software development, aimed at improving the internal code structure in order to make it easier to understand and modify.<n>It is often assumed that makes the code less prone to bugs.<n>However, in practice, is a complex task and applied in different ways. Therefore, certains can inadvertently make the code more prone to bugs.
• Score: 43.65862440745159
• License: http://creativecommons.org/licenses/by/4.0/
• Abstract: Refactoring is a common practice in software development, aimed at improving the internal code structure in order to make it easier to understand and modify. Consequently, it is often assumed that refactoring makes the code less prone to bugs. However, in practice, refactoring is a complex task and applied in different ways (e.g., various refactoring types, single vs. composite refactorings) and with a variety of purposes (e.g., root-canal vs. floss refactoring). Therefore, certain refactorings can inadvertently make the code more prone to bugs. Unfortunately, there is limited research in the literature on the long-term relationship between the different characteristics of refactorings and bugs. This paper presents a longitudinal study of 12 open source software projects, where 27,450 refactorings, 6,051 reported bugs, and 49,250 bugs detected with static analysis tools were analyzed. While our study confirms the common intuition that refactored code is less bug-prone than non-refactored code, we also extend or contradict existing body of knowledge in other ways. First, a code element that undergoes multiple refactorings is not less bug-prone than an element that undergoes a single refactoring. A single refactoring is the one not performed in conjunction with other refactorings in the same commit. Second, single refactorings often induce the occurrence of bugs across all analyzed projects. Third, code elements affected by refactorings made in conjunction with other non-refactoring changes in the same commit (i.e., floss refactorings) are often bug-prone. Finally, many of such bugs induced by refactoring cannot be revealed with state-of-the-art techniques for detecting behavior-preserving refactorings.

Related papers

• Bugs in the Shadows: Static Detection of Faulty Python Refactorings [44.115219601924856]
  Python's dynamic type system poses significant challenges for automated code transformations.<n>Our analysis uncovered 29 bugs across four types from a total of 1,152 attempts.<n>These results highlight the need to improve the robustness of current Python tools to ensure the correctness of automated code transformations.
  arXiv  Detail & Related papers  (2025-07-01T18:03:56Z)
• Relating Complexity, Explicitness, Effectiveness of Refactorings and Non-Functional Requirements: A Replication Study [39.82126443893643]
  Self-affirmed (SAR) is where developers explicitly state their intent to simplify requirements.<n>This study expanded the scope of Soares et al.'s study by doubling the number of projects and a significantly larger set of validated instances.<n>We observed that when developers explicitly state their intent, the resulting changes typically involve a combination of different types, making them more complex.
  arXiv  Detail & Related papers  (2025-05-12T19:26:33Z)
• Refactoring Detection in C++ Programs with RefactoringMiner++ [45.045206894182776]
  We present RefactoringMiner++, a detection tool based on the current state of the art: RefactoringMiner 3.<n>While the latter focuses exclusively on Java, our tool is seeded -- to the best of our knowledge -- the first publicly available detection tool for C++ projects.
  arXiv  Detail & Related papers  (2025-02-24T23:17:35Z)
• Testing Refactoring Engine via Historical Bug Report driven LLM [6.852749659993347]
  Refactoring is the process of restructuring existing code without changing its external behavior.<n>We propose RETESTER, a framework for automated engine testing.
  arXiv  Detail & Related papers  (2025-01-16T23:31:49Z)
• An Empirical Study of Refactoring Engine Bugs [7.412890903261693]
  We present the first systematic study of engine bugs by analyzing bugs in Eclipse, IntelliJ IDEA, and Netbeans. We analyzed these bugs according to their types, symptoms, root causes, and triggering conditions. Our transferability study revealed 130 new bugs in the latest version of those engines.
  arXiv  Detail & Related papers  (2024-09-22T22:09:39Z)
• ReGAL: Refactoring Programs to Discover Generalizable Abstractions [59.05769810380928]
  Generalizable Abstraction Learning (ReGAL) is a method for learning a library of reusable functions via codeization. We find that the shared function libraries discovered by ReGAL make programs easier to predict across diverse domains. For CodeLlama-13B, ReGAL results in absolute accuracy increases of 11.5% on LOGO, 26.1% on date understanding, and 8.1% on TextCraft, outperforming GPT-3.5 in two of three domains.
  arXiv  Detail & Related papers  (2024-01-29T18:45:30Z)
• RefBERT: A Two-Stage Pre-trained Framework for Automatic Rename Refactoring [57.8069006460087]
  We study automatic rename on variable names, which is considered more challenging than other rename activities. We propose RefBERT, a two-stage pre-trained framework for rename on variable names. We show that the generated variable names of RefBERT are more accurate and meaningful than those produced by the existing method.
  arXiv  Detail & Related papers  (2023-05-28T12:29:39Z)
• Do code refactorings influence the merge effort? [80.1936417993664]
  Multiple contributors frequently change the source code in parallel to implement new features, fix bugs, existing code, and make other changes. These simultaneous changes need to be merged into the same version of the source code. Studies show that 10 to 20 percent of all merge attempts result in conflicts, which require the manual developer's intervention to complete the process.
  arXiv  Detail & Related papers  (2023-05-10T13:24:59Z)
• How We Refactor and How We Document it? On the Use of Supervised Machine Learning Algorithms to Classify Refactoring Documentation [25.626914797750487]
  Refactoring is the art of improving the design of a system without altering its external behavior. This study categorizes commits into 3 categories, namely, Internal QA, External QA, and Code Smell Resolution, along with the traditional BugFix and Functional categories. To better understand our classification results, we analyzed commit messages to extract patterns that developers regularly use to describe their smells.
  arXiv  Detail & Related papers  (2020-10-26T20:33:17Z)

This list is automatically generated from the titles and abstracts of the papers in this site.

This site does not guarantee the quality of this site (including all information) and is not responsible for any consequences.