Extract Method Refactoring Overview

• Extract Method Refactoring is a refactoring technique that moves code fragments from long methods into newly created, semantically named methods to enhance readability and maintainability.
• It addresses intents such as decomposing long methods, removing duplicated code, and separating concerns, thereby improving testability and reusability.
• Research approaches range from rule-based static analysis to machine learning and language-model techniques, validated through systematic studies and industrial evaluations.

Searching arXiv for recent and foundational papers on Extract Method Refactoring to ground the article in published work. Extract Method Refactoring (EMR) is a method-level refactoring in which a selection of code from inside the body of an existing method is moved into a new method, and the original code is replaced with a call to that method. In the literature, EMR is treated both as a basic refactoring for improving understandability, maintainability, reuse, and testability, and as a higher-level decomposition mechanism for long methods, duplicated code, and separation of concerns. A systematic literature review of EMR research identified 83 primary studies, spanning work from 1998 to 2023, and characterized the area as a mature but heterogeneous research field with substantial attention to recommendation, automation, and validation (AlOmar et al., 2021, AlOmar et al., 2023).

1. Definition and conceptual scope

The canonical procedural description of EMR in the surveyed literature is stable: determine the code to be extracted, create a new method from that code, give the new method a clear name, and replace the original code with a call to the new method. The name is not a cosmetic afterthought; one recommendation paper makes the naming step central, arguing that EMR is incomplete until the extracted fragment can be assigned a clear, semantically appropriate method name (Yamanaka et al., 2021).

Within broader refactoring taxonomies, EMR occupies an unusually central position. The systematic review describes it as the “Swiss army knife” of refactorings and organizes EMR research along six dimensions: intent, code analysis, code representation, detection, execution, and validation method. The same review reports that EMR research is distributed across three dominant intents—code clone, separation of concerns, and long method—with code clones accounting for 38.6% of studies, separation of concerns 34.9%, and long method 26.5% (AlOmar et al., 2023).

EMR also appears as a foundational operation in catalogs beyond single refactorings. In the composite-refactoring literature, repeated EMR steps over the same method are elevated to “Method Decomposition,” while repeated EMR steps over duplicated code at multiple locations are elevated to “Method Composition.” This framing treats individual extractions not as isolated edits but as elements of a larger structural transformation (Brito et al., 2022).

2. Motivations and intents in practice

Empirical evidence from GitHub and Stack Overflow shows that EMR is used for substantially more than long-method cleanup. A study of recent GitHub refactorings found that Extract Method was the most versatile refactoring operation, serving 11 different purposes. The reported motivations and counts were: extract reusable method (43), introduce alternative method signature (25), decompose method to improve readability (21), facilitate extension (15), remove duplication (14), replace method preserving backward compatibility (6), improve testability (6), enable overriding (4), enable recursion (2), introduce factory method (1), and introduce async operation (1). The same study emphasizes that only 2 of the 11 motivations were primarily code-smell-oriented—decompose method to improve readability and remove duplication—and that these accounted for only 25% (35/138) of the motivation instances (Silva et al., 2016).

Stack Overflow discussions show a related but linguistically different picture. In a corpus collected through questions with a tag containing refactor or with refactor in the title, the generic keyword extract* appeared with a frequency of 2.71% among matched SAR patterns, while long method appeared with 3.84%. The bigram extract method frequently occurred in question posts, but the paper stresses that developers “rarely utilize established refactoring terminology (e.g., Extract Method') when describing their problem”; instead they use colloquial descriptions such as “make it more readable and compact,” “shrink the following code,” “helper method,” “avoid duplication,” or “split” code. In the same dataset, the largest latent topic was Code Optimization with 4,142 questions (43.72%), characterized by words such ashelper_method,avoid_duplication,switch_statement,lambda_expression,repeated,function, andvariable` (Peruma et al., 2021).

This practical evidence suggests that EMR is best understood as an intent-rich transformation rather than a single smell-removal rule. The literature repeatedly ties it to readability, testability, reuse, duplicate-code removal, complexity reduction, and separation of responsibilities, but the triggering vocabulary in real workflows is often indirect and task-oriented rather than catalog-oriented (Peruma et al., 2021, Silva et al., 2016).

3. Opportunity identification and recommendation techniques

The EMR literature spans structural, syntactic, semantic, and hybrid analyses, using representations such as source code, ASTs, graphs, metrics, tokens, and text. The systematic review reports that 53% of studies include the developer in the loop and 61% provide multiple candidate solutions or alternatives, which indicates that recommendation has historically been at least as important as full automation (AlOmar et al., 2023).

A representative structural approach is JExtract, an Eclipse plug-in that identifies contiguous statement subsequences inside a block of linear control flow, filters them using Eclipse Extract Method preconditions, and ranks them by structural dissimilarity between the candidate fragment and the remaining code. Its scoring function compares variable, type, and package dependencies using a distance derived from the Kulczynski similarity coefficient:

$$dist(Dep',Dep'') = 1 - \frac{1}{2}\Big[\frac{a}{(a+b)}+\frac{a}{(a+c)}\Big]$$

where $a = |Dep' \cap Dep''|$, $b = |Dep' \setminus Dep''|$, and $c = |Dep'' \setminus Dep'|$. The overall score averages the distances over variables, types, and packages:

$$\mathit{score}(m') = \frac{1}{3}\, dist(\mathit{Dep}_{var}(m'), \mathit{Dep}_{var}(m'')) + \frac{1}{3}\, dist(\mathit{Dep}_{type}(m'), \mathit{Dep}_{type}(m'')) + \frac{1}{3}\, dist(\mathit{Dep}_{pack}(m'), \mathit{Dep}_{pack}(m''))$$

In its evaluation, JExtract reported Top-1 recall and precision of 46% and 46% on one study, substantially above JDeodorant’s reported recall of 4% and precision of 6% in the same setting (Silva et al., 2015).

Graph- and slice-based methods pursue a different notion of extractability. Segmentation constructs a Structure Dependence Graph (SDG) over a language-independent intermediate representation and contracts it using structural control edge contraction, exclusive data dependence edge contraction, and sequential data dependence contraction; its tuned thresholds include $LoCS = 0.41$ and $PA = 0.34$ (Tiwari et al., 2019). SBSRE, by contrast, defines a method’s responsibilities through output instructions and computes output-based backward slices; it reports at least a 29.6% improvement in precision and a 12.1% improvement in recall over state-of-the-art approaches on the GEMS benchmark, together with an average cohesion improvement of about 20% after refactoring (Ardalani et al., 2023).

Learning-based recommenders increasingly incorporate semantic signals not captured by classic cohesion and coupling metrics. A notable example extends GEMS with a single additional feature, CODE2SEQ_CONFIDENCE, derived from method-name prediction confidence. The resulting model computes 49 features per candidate—48 GEMS features plus the code2seq confidence—and ranks candidates by predicted probability. At 3% tolerance, its top-5 F-measure improved from 0.30310 to 0.32632, and CODE2SEQ_CONFIDENCE became the most important feature with Gini importance 0.30011 (Yamanaka et al., 2021).

Industrial prediction work adopts a coarser perspective by classifying methods before refactoring occurs. In a study at ING, the dataset contained 919 EMR instances and 986 non-EMR instances across 18 internal projects. The best within-ING model was Random Forest, with Accuracy 0.934, F1 0.935, Precision 0.899, and Recall 0.973. Permutation importance showed that class-level features such as UW, CBO, LCOM, LOC, and RFC were more influential than method-level features, implying that extractability is shaped by the surrounding class context as well as by the method body (Leij et al., 2021).

4. Human decision-making, documentation, and cognitive evidence

Controlled evidence on how developers choose extraction boundaries shows substantial regularity but not uniformity. In an experiment based on flattened production code from requests/adapters.py, 23 participants produced 142 extracted functions. Of these, 77 started on an if and 31 on a try, which the authors interpret as evidence that developers rely heavily on visible control-flow structure when performing EMR. Participants extracted between 3 and 10 functions, and the amount of code extracted ranged from 37% to 95%. Most extracted functions were short: 80% were 5–30 LOC and 55% were 10–14 LOC (Braver et al., 2022).

The same experiment indicates that developers prioritize cohesion and responsibility more than raw length minimization. On a 1–5 scale, the mean ratings were 4.62 for “Making each function's logic cohesive,” 4.10 for “Making each function do only one thing,” 3.93 for “Separating code control blocks,” and 3.89 for “Making functions easily testable,” whereas “Making functions as short as possible” and “Making each function close to the ideal length” received 2.72 and 2.65. This suggests that short extracted methods are often a consequence of other design criteria rather than an explicit optimization target (Braver et al., 2022).

Textual documentation around EMR is informative but far from standardized. A multiclass commit-message study over 5,004 commits balanced across six method-level refactoring types included 834 Extract Method instances. Extract Method was among the best documented refactoring activities. Its best per-class result came from Gradient Boosted Machine with Precision 0.71, Recall 0.68, and F1 0.69. By comparison, a keyword baseline using extract achieved Precision 76%, Recall 30%, and F-measure 44%, showing that developers often document EMR indirectly through patterns such as “add* a new method,” “split* up a complex method,” “separat* a method,” or “break* up the jumbo methods,” rather than by naming the refactoring explicitly (AlOmar et al., 2021).

Cognitive evidence further complicates the assumption that extraction uniformly improves comprehension. An eye-tracking study with 32 Java novices found that effects were task-dependent: in two tasks, method extraction improved performance and reduced visual effort, with time decreasing by up to 78.8% and regressions by 84.6%; in simpler tasks, extraction hurt performance, with time increasing by up to 166.9% and regressions by 200%. The study reports that even with meaningful method names, novices often switched back and forth between call sites and extracted methods, increasing navigation and cognitive load. This does not negate EMR’s value, but it indicates that the benefits of abstraction depend on task complexity and reader expertise (Costa et al., 20 Feb 2026).

5. Automation, IDE integration, and language-model-based EMR

Before the emergence of LLMs, IDE-centered automation already targeted workflow integration. AntiCopyPaster, an IntelliJ IDEA plugin for just-in-time duplicate-code extraction, trained a Convolutional Neural Network on 18,942 code fragments from 13 Apache projects and reported Precision 0.82, Recall 0.82, F-measure 0.82, and PR-AUC 0.86. Its plugin monitored paste events, computed 78 PSI-based metrics, and invoked IntelliJ’s built-in Extract Method API when the classifier predicted that the pasted fragment resembled historically extracted code. In a qualitative study with 72 developers, the logged values included notificationCount = 63, extractMethodAppliedCount = 59, and extractMethodCanceledCount = 0 (AlOmar et al., 2023). A different IntelliJ plugin, the Live Refactoring Environment, emphasized continuous visual guidance: in a controlled experiment, the fully live group A1 averaged 16 refactorings versus 6 in the no-tool group B, and its reported Time Efficiency was 29 versus 60 for group B (Fernandes et al., 2023).

Recent work combines LLMs with static analysis rather than replacing static analysis outright. EM-Assist, implemented as an IntelliJ IDEA plugin for Java and Kotlin, uses few-shot prompting to generate extraction candidates, filters hallucinations with IDE preconditions, enhances candidates via program slicing, ranks them, and delegates actual transformation to IntelliJ’s refactoring engine. A formative study over 1,752 EM scenarios reported that 76.3% of raw LLM suggestions were hallucinations, broken down into 57.4% invalid and 18.9% not useful. After filtering and ranking, EM-Assist suggested the developer-performed refactoring in 53.4% of cases on the 1,752-refactoring corpus, compared with 39.4% for JExtract. The reported statistical evidence includes $p\text{-value} < 10^{-5}$ in one evaluation and a Hodges-Lehmann difference of 12.4 percentage points in another. In a firehose survey with 16 industrial developers, 81.3% agreed with the recommendations; in a separate usability survey with 18 industrial developers, 94.4% gave a positive rating (Pomian et al., 2024, Pomian et al., 2024).

Fully generative EMR has also become a benchmark for code LMs. A comparative study on Python evaluated five open-source LLMs on 840 CodeNet samples and found that Recursive Criticism and Improvement outperformed one-shot prompting. DeepSeek-Coder-RCI achieved Test Pass Percentage 0.829, while Qwen2.5-Coder-RCI achieved 0.808; the corresponding LOC-per-method values fell from 12.103 in the original code to 6.192 and 5.577, and cyclomatic complexity fell from 4.602 to 3.453 and 3.294. A developer survey on RCI-generated refactorings reported over 70% acceptance, but the same paper notes that LOC and CC often diverge from human judgments (Chand et al., 30 Oct 2025). On Java, reinforcement-learning alignment has been used to fine-tune sequence-to-sequence models for full refactored-code generation. In that setting, Code-T5 plus PPO reached BLEU 75.91, CodeBLEU 61.87, syntactical correctness 85.7%, compilation success 79.8%, and 66 passing unit tests out of 122, compared with 41 for the best supervised-only baseline (Palit et al., 2024).

6. Composite transformations, benchmarks, and unresolved issues

EMR is frequently not a terminal event in software history but an atomic step inside larger refactoring structures. A catalog of composite refactorings defines Method Decomposition as two or more Extract Method operations over a single method and Method Composition as two or more EMR operations over duplicated code that produce a shared method. In a representative refactoring oracle, 1,043 of 1,725 operations (60.5%) belonged to composites. Within that set, Method Composition accounted for 142 occurrences and 537 operations, or 38.8% of composite occurrences, while Method Decomposition accounted for 125 occurrences and 295 operations, or 34.1%. In a full-history study of ten projects, the authors detected 2,886 composite refactorings overall, including 683 Method Decompositions (23.7%) and 582 Method Compositions (20.2%); 448 composites (15.5%) spanned multiple commits, with median age 186 days (Brito et al., 2022).

Benchmarking remains one of the area’s most persistent weaknesses. The systematic review reports that 86.74% of EMR datasets are created by the paper authors, only 13.25% reuse datasets from previous studies, and 78.31% are not publicly available. It also notes that only 11 tools report accuracy information in a sufficiently explicit way, that 81.92% of studies target Java, and that only 18 of the 37 identified tools could be located publicly online. The review therefore argues for public benchmarks, intent-labeled refactoring instances, clearer metric thresholds and decision rules, and better integration of naming support and developer workflows (AlOmar et al., 2023).

Language specificity further complicates standardization. A recent C# study on clone refactoring with lambda expressions evaluated 2,217 clone pairs from 22 projects and reported that 35.0% were suitable for refactoring and that 28.9% were successfully refactored. Its central claim is that behavior parameterization via lambda expressions materially changes which clone pairs are refactorable, implying that the optimal EMR technique varies with language semantics rather than merely with clone structure (Kawamoto et al., 25 Dec 2025).

Taken together, these results portray EMR as a foundational but context-sensitive refactoring. It is simultaneously a developer practice, a recommendation problem, a code-generation problem, a documentation problem, and a benchmark-design problem. The literature consistently shows that identifying good extraction boundaries, assigning meaningful names, preserving behavior, aligning with developer intent, and validating results across heterogeneous datasets remain the defining technical challenges of EMR research (AlOmar et al., 2023, Pomian et al., 2024).