Automated Detection of Refactorings in Evolving Components

Dig, Danny; Comertoglu, Can; Marinov, Darko; Johnson, Ralph E.

doi:10.1007/11785477_24

Cited by 187 publications

(170 citation statements)

References 19 publications

Supporting

Mentioning

168

Contrasting

Unclassified

Order By: Relevance

“…Our results indicate that most of the time, refactorings are tightly intermixed with other refactorings or manual edits before reaching VCS. This could severely undermine the effectiveness of refactoring inference tools that are based on VCS snapshots [10,11,21,29,49,50]. Our findings serve as a strong motivation to build a refactoring inference tool based on the precise, fine-grained data collected by CodingTracker and compare its accuracy against the existing snapshot-based tools.…”

Section: How Much Do Developers Intersperse Refactorings and Edits Inmentioning

confidence: 93%

“…Many tools [10,11,21,29,49,50] compare a program's snapshots stored in VCS to infer the refactorings applied to it. As the first step, such a tool employs different similarity measures to match the refactored program entities in the two compared snapshots.…”

Section: How Much Do Developers Intersperse Refactorings and Edits Inmentioning

confidence: 99%

“…Next, the tool uses the difference between the two matched program entities as an indicator of the kind of the applied refactoring. For example, two methods with different names but with similar code statements could serve as an evidence of a Rename Method refactoring [11]. If a refactored program entity is additionally changed in the same commit, both matching it across commits and deciding on the kind of refactoring applied to it become harder.…”

Section: How Much Do Developers Intersperse Refactorings and Edits Inmentioning

confidence: 99%

“…Weissgerber et al [50] and Dig et al [11] proposed tools for identifying refactorings between two different version of a source code. Such tools help developers gain better insights into the high-level transformations that occurred between different versions of a program.…”

Section: Tools For Reconstructing Program Changesmentioning

confidence: 99%

“…Therefore, code evolution research performed on the snapshots stored in the VCS (like in [16][17][18]) does not account for shadowed code changes. Ignoring shadowed changes could significantly limit the accuracy of tools that try to infer the intent of code changes (e.g., infer refactorings [10,11,21,49,50], infer bug fixes [23,30,32,33,39,53]). …”

Section: Introductionmentioning

confidence: 99%

See 4 more Smart Citations

Is It Dangerous to Use Version Control Histories to Study Source Code Evolution?

Negara

Vakilian

Chen

et al. 2012

ECOOP 2012 – Object-Oriented Programming

Self Cite

View full text Add to dashboard Cite

Abstract. Researchers use file-based Version Control System (VCS) as the primary source of code evolution data. VCSs are widely used by developers, thus, researchers get easy access to historical data of many projects. Although it is convenient, research based on VCS data is incomplete and imprecise. Moreover, answering questions that correlate code changes with other activities (e.g., test runs, refactoring) is impossible. Our tool, CodingTracker, non-intrusively records fine-grained and diverse data during code development. CodingTracker collected data from 24 developers: 1,652 hours of development, 23,002 committed files, and 314,085 testcase runs. This allows us to answer: How much code evolution data is not stored in VCS? How much do developers intersperse refactorings and edits in the same commit? How frequently do developers fix failing tests by changing the test itself? How many changes are committed to VCS without being tested? What is the temporal and spacial locality of changes?

show abstract

Section: How Much Do Developers Intersperse Refactorings and Edits Inmentioning

confidence: 93%

Section: How Much Do Developers Intersperse Refactorings and Edits Inmentioning

confidence: 99%

Section: How Much Do Developers Intersperse Refactorings and Edits Inmentioning

confidence: 99%

Section: Tools For Reconstructing Program Changesmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Is It Dangerous to Use Version Control Histories to Study Source Code Evolution?

Negara

Vakilian

Chen

et al. 2012

ECOOP 2012 – Object-Oriented Programming

Self Cite

View full text Add to dashboard Cite

show abstract

A survey and taxonomy of approaches for mining software repositories in the context of software evolution

Kagdi

Collard

Maletic

2007

J. Softw. Maint. Evol.: Res. Pract.

313

195

View full text Add to dashboard Cite

SUMMARYA comprehensive literature survey on approaches for mining software repositories (MSR) in the context of software evolution is presented. In particular, this survey deals with those investigations that examine multiple versions of software artifacts or other temporal information. A taxonomy is derived from the analysis of this literature and presents the work via four dimensions: the type of software repositories mined (what), the purpose (why), the adopted/invented methodology used (how), and the evaluation method (quality). The taxonomy is demonstrated to be expressive (i.e., capable of representing a wide spectrum of MSR investigations) and effective (i.e., facilitates similarities and comparisons of MSR investigations). Lastly, a number of open research issues in MSR that require further investigation are identified. Copyright

show abstract

Research on mining software repositories to facilitate refactoring

Nyamawe

2023

WIREs Data Min & Knowl

View full text Add to dashboard Cite

Software refactoring focuses on improving software quality by applying changes to the internal structure that do not alter the observable behavior. Determining which refactorings should be applied and presented to developers the most relevant and optimal refactorings is often challenging. Existing literature suggests that one of the potential sources to identify and recommend required refactorings is the past software development and evolution histories which are often archived in software repositories. In this article, we review a selection of existing literature that has attempted to propose approaches that facilitate refactoring by exploiting information mined from software repositories. Based on the reviewed papers, existing works leverage software history mining to support analysis of code smells, refactoring, and guiding software changes. First, past history information is used to detect design flaws in source code commonly referred to as code smells. Moreover, other studies analyze the evolution of code smells to establish how and when they are introduced into the code base and get resolved. Second, software repositories mining provides useful insights that can be used in predicting the need for refactoring and what specific refactoring operations are required. In addition, past history can be used in detecting and analyzing previously applied refactorings to establish software change facts, for instance, how developers refactor code and the motivation behind it. Finally, change patterns are used to predict further changes that might be required and recommend a set of files for change during a given modification task. The paper further suggests other exciting possibilities that can be pursued in the future in this research direction.This article is categorized under: Algorithmic Development > Text Mining Application Areas > Data Mining Software Tools

show abstract

Automated Detection of Refactorings in Evolving Components

Cited by 187 publications

References 19 publications

Is It Dangerous to Use Version Control Histories to Study Source Code Evolution?

Is It Dangerous to Use Version Control Histories to Study Source Code Evolution?

A survey and taxonomy of approaches for mining software repositories in the context of software evolution

Research on mining software repositories to facilitate refactoring

Contact Info

Product

Resources

About