論文の概要: Assessing the Bug-Proneness of Refactored Code: A Longitudinal Multi-Project Study

• arxiv url: http://arxiv.org/abs/2505.08005v1
• Date: Mon, 12 May 2025 19:12:30 GMT
• ステータス: 翻訳完了
• システム内更新日: 2025-05-14 20:57:54.312992
• Title: Assessing the Bug-Proneness of Refactored Code: A Longitudinal Multi-Project Study
• Title（参考訳）: リファクタリングコードのバグ性評価 : 長期的マルチプロジェクト研究
• Authors: Isabella Ferreira, Lawrence Arkoh, Anderson Uchôa, Ana Carla Bibiano, Alessandro Garcia, Wesley K. G. Assunção,
• Abstract要約: リファクタリングはソフトウェア開発で一般的なプラクティスで、内部のコード構造を改善して、理解と修正を容易にすることを目的としています。 しばしば、コードがバグに弱いと仮定される。 しかし、実際には複雑なタスクであり、異なる方法で適用されている。そのため、不注意にもコードをバグに陥れやすいものにすることができる。
• 参考スコア（独自算出の注目度）: 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.
• Abstract（参考訳）: リファクタリングはソフトウェア開発で一般的なプラクティスで、内部のコード構造を改善して、理解と修正を容易にすることを目的としています。 その結果、リファクタリングによってコードがバグを起こしにくくなると仮定されることが多い。 しかし実際には、リファクタリングは複雑なタスクであり、さまざまな方法(例えば、さまざまなリファクタリングタイプ、シングル対コンポジットリファクタリング)と、さまざまな目的(例えば、ルートカナル対フロスリファクタリング)で適用されます。 したがって、あるリファクタリングは必然的にコードをバグにしやすくする。 残念ながら、リファクタリングの異なる特性とバグの長期的な関係についての研究は、文献で限られています。 本稿では,12のオープンソースプロジェクトについて,27450件のリファクタリング,6,051件のバグ,49,250件のバグを静的解析ツールを用いて解析した。 我々の研究は、リファクタリングされたコードは非リファクタリングされたコードよりもバグを起こしやすいという一般的な直感を裏付けていますが、他の方法で既存の知識体系を拡張したり、矛盾させたりします。 まず、複数のリファクタリングを行うコード要素は、単一のリファクタリングを行う要素よりもバグを起こしやすい。 単一のリファクタリングは、同じコミットで他のリファクタリングと一緒に実行されないものなのです。 第2に、単一リファクタリングは、分析されたすべてのプロジェクトに対して、しばしばバグの発生を誘発します。 第三に、同じコミットで他の非リファクタリング変更(つまり、フロスリファクタリング)と連動してリファクタリングによって影響を受けるコード要素は、しばしばバグを起こします。 最後に、リファクタリングによって引き起こされる多くのバグは、動作保存リファクタリングを検出する最先端の技術では明らかにできない。

関連論文リスト

• Relating Complexity, Explicitness, Effectiveness of Refactorings and Non-Functional Requirements: A Replication Study [39.82126443893643]
  自己確認(Self-affirmed、SAR)とは、開発者が要求を単純化する意図を明確に述べる場所である。 本研究は、プロジェクト数と検証済みインスタンスのセットを2倍にすることで、Soaresらの研究の範囲を広げた。 開発者が明示的に意図を述べると、結果として得られる変更は一般的に異なる型の組み合わせを伴い、より複雑なものになります。
  論文  参考訳（メタデータ） (2025-05-12T19:26:33Z)
• Refactoring Detection in C++ Programs with RefactoringMiner++ [45.045206894182776]
  RefactoringMiner++は、現在の技術状況に基づいた検出ツールである。 後者はJavaに特化していますが、私たちのツールには、私たちの知る限り、C++プロジェクトで最初に公開された検出ツールがシードされています。
  論文  参考訳（メタデータ） (2025-02-24T23:17:35Z)
• Testing Refactoring Engine via Historical Bug Report driven LLM [6.852749659993347]
  リファクタリングは、外部の振る舞いを変えることなく、既存のコードを再構築するプロセスである。 自動エンジンテストのためのフレームワークであるRETESTERを提案する。
  論文  参考訳（メタデータ） (2025-01-16T23:31:49Z)
• An Empirical Study of Refactoring Engine Bugs [7.412890903261693]
  Eclipse、IntelliJ IDEA、Netbeansのバグを分析することで、エンジンのバグに関する最初の体系的な研究を示す。 これらのバグは, タイプ, 症状, 根本原因, トリガー条件によって分析した。 我々のトランスファービリティー調査では、これらのエンジンの最新バージョンに130の新たなバグが見つかった。
  論文  参考訳（メタデータ） (2024-09-22T22:09:39Z)
• ReGAL: Refactoring Programs to Discover Generalizable Abstractions [59.05769810380928]
  Generalizable Abstraction Learning (ReGAL)は、再利用可能な関数のライブラリをコード化して学習する手法である。 ReGALによって発見された共有関数ライブラリは、プログラムが様々な領域で容易に予測できることを示している。 CodeLlama-13Bでは、ReGALはLOGOで11.5%、日付理解で26.1%、TextCraftで8.1%という絶対精度が向上し、3つのドメインのうち2つでGPT-3.5を上回った。
  論文  参考訳（メタデータ） (2024-01-29T18:45:30Z)
• RefBERT: A Two-Stage Pre-trained Framework for Automatic Rename Refactoring [57.8069006460087]
  本研究では,他のリネーム活動よりも難易度の高い変数名の自動改名について検討する。 変数名に対する名前変更のための2段階事前訓練フレームワークであるRefBERTを提案する。 RefBERTの変数名は既存の手法よりも正確で有意義であることを示す。
  論文  参考訳（メタデータ） (2023-05-28T12:29:39Z)
• Do code refactorings influence the merge effort? [80.1936417993664]
  複数のコントリビュータがソースコードを並行して変更して,新機能の実装やバグの修正,既存のコードの変更などを行っている。 これらの同時変更は、ソースコードの同じバージョンにマージする必要がある。 研究によると、すべてのマージの試みの10～20%が衝突を起こしており、これはプロセスを完了するために手動開発者の介入を必要とする。
  論文  参考訳（メタデータ） (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]
  リファクタリングは、外部の振る舞いを変えることなく、システムの設計を改善する技術である。 この研究はコミットを、従来のBugFixやFunctionalのカテゴリとともに、内部QA、外部QA、Code Smell Resolutionの3つのカテゴリに分類する。 分類結果をよりよく理解するために、私たちはコミットメッセージを分析して、開発者が定期的に臭いを説明するために使用するパターンを抽出しました。
  論文  参考訳（メタデータ） (2020-10-26T20:33:17Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。