CodeShovel: Constructing Method-Level Source Code Histories

Grund, Felix; Chowdhury, Shaiful Alam; Bradley, N; Hall, Braxton; Holmes, Reid

doi:10.1109/icse43902.2021.00135

Cited by 22 publications

(15 citation statements)

References 54 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In this paper we focus on size thresholds at the method-level granularity. Method level is the most desirable to the developers, because class/file, or module-level granularities are often too coarse to be practically useful [24,29,62,75].…”

Section: Related Workmentioning

confidence: 99%

“…We addressed the selection bias threat by selecting all the GitHub projects used by five different previous studies (specifically from [26,29,60,67,78]), resulting in 49 open-source Java projects. Table 1 summarizes the dataset.…”

Section: Project Selectionmentioning

confidence: 99%

“…To understand the relationship between method size and change-/bug-proneness, we need method-level evolution history. We used the state-of-the-art history tracing tool CodeShovel [28,29], which returns the complete change history of a given method. CodeShovel also collects information about when a method was modified, who…”

Section: Data Collectionmentioning

confidence: 99%

“…Capturing bug related keywords from the commit messages for measuring bug-proneness is only ∼80% accurate [78]. Also, the CodeShovel tool [28] we used for capturing method history is accurate only for 90% of the methods [29].…”

Section: Threats To Validitymentioning

confidence: 99%

“…Unfortunately, there is no evidence-based guidelines that developers can follow to optimize the size of their components. In this paper we focus on method level granularity to measure size (e.g., in contrast to class-, or module-level granularities), because method level granularity is desired by both developers and researchers [29,62]. There is not currently broad consensus for how long a method should be; for example, consider 'What is the ideal length of a method for you?'…”

Section: Introductionmentioning

confidence: 99%

See 4 more Smart Citations

An Empirical Study on Maintainable Method Size in Java

Chowdhury¹,

Uddin²,

Holmes³

2022

Preprint

Self Cite

View full text Add to dashboard Cite

Code metrics have been widely used to estimate software maintenance effort. Metrics have generally been used to guide developer effort to reduce or avoid future maintenance burdens. Size is the simplest and most widely deployed metric. The size metric is pervasive because size correlates with many other common metrics (e.g., McCabe complexity, readability, etc.). Given the ease of computing a method's size, and the ubiquity of these metrics in industrial settings, it is surprising that no systematic study has been performed to provide developers with meaningful method size guidelines with respect to future maintenance effort. In this paper we examine the evolution of ∼785K Java methods and show that developers should strive to keep their Java methods under 24 lines in length. Additionally, we show that decomposing larger methods to smaller methods also decreases overall maintenance efforts. Taken together, these findings provide empirical guidelines to help developers design their systems in a way that can reduce future maintenance. CCS Concepts• Software engineering → Code metrics.

show abstract

Section: Related Workmentioning

confidence: 99%

Section: Project Selectionmentioning

confidence: 99%

Section: Data Collectionmentioning

confidence: 99%

Section: Threats To Validitymentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

An Empirical Study on Maintainable Method Size in Java

Chowdhury¹,

Uddin²,

Holmes³

2022

Preprint

Self Cite

View full text Add to dashboard Cite

show abstract

Towards a catalog of composite refactorings

Brito

Hora

Valente

2023

J Software Evolu Process

View full text Add to dashboard Cite

Catalogs of refactoring have key importance in software maintenance and evolution, since developers rely on such documents to understand and perform refactoring operations. Furthermore, these catalogs constitute a reference guide for communication between practitioners since they standardize a common refactoring vocabulary. Fowler's book describes the most popular catalog of refactorings, which documents single and well‐known refactoring operations. However, sometimes, refactorings are composite transformations, that is, a sequence of refactorings is performed over a given program element. For example, a sequence of Extract Method operations (a single refactoring) can be performed over the same method, in one or in multiple commits, to simplify its implementation, therefore, leading to a Method Decomposition operation (a composite refactoring). In this paper, we propose and document a catalog with eight composite refactorings. We also implement a set of scripts to mine composite refactorings by preprocessing the results of refactoring detection tools. Using such scripts, we search for composites in a representative refactoring oracle with hundreds of confirmed single refactoring operations. Next, to complement this first study, we also search for composites in the full history of 10 well‐known open‐source projects. We characterize the detected composite refactorings, under dimensions such as size and location. We conclude by addressing the applications and implications of the proposed catalog.

show abstract