Formalizing and Automating Fine-Grained Move Refactorings Across Methods

Motivation

• Fine-grained moves are used in real projects, with Localize Parameter performed an average of 31.56 times per project, despite insufficient foundations for formalizing and automating them.Localize Parameter moves a statement or expression from a call site into the callee method.Source: §I · p. 1

Scope

• The work automates the mechanics of applying a move when its statically checked conditions hold, while deciding where code should move remains a complementary recommendation problem.Potential side-effect reordering is left to developer judgment, and the automated mechanics ensure that a recommended move can be applied without breaking statically checked conditions.Source: §I · pp. 1–2

Motivation

• Formalized fine-grained moves provide a statically checked execution layer complementary to LLM-based judgments about where code should live.The paper argues that explicit static checks can support deterministic application of moves selected by a developer or an LLM.Source: §I · p. 2

Contributions

• The formalization defines five Move Statement and three Move Expression variants using four conditions for data reachability, execution count, side effects, and compilation constraints.Four Move Statement variants and one Move Expression variant are newly formalized; all conditions except side effects are statically guaranteed.Source: §I · pp. 1–2
• An iterative refinement methodology adds twenty preconditions or steps based on failures observed in a real project.These additional rules address practical Java syntactic diversity.Source: §I · p. 2

Evaluation

• 93.3–97.0% of applicable cases compile in the evaluation across ten projects, which also includes a test-based case study and a taxonomy of compile failures.The paper evaluates applicability and compilability across ten projects.Source: §I · p. 2

• In dbeaver, moving addObjectExtraActions preserves behavior when its callee is called only by the target caller, but manual execution requires replacing inaccessible command with this.Source: §II · p. 2
• Moving a login print statement before the assignment changes the printed value of isLogin from true to false, motivating safety preconditions for automated moves.Source: §II · p. 2
• Fowler’s Slide Statements reorder statements within a method, while MS→ and MS← move statements across method boundaries; these moves aim to improve readability and modularization.Source: §II · pp. 2–3
• Fowler’s definitions lack preconditions, cross-method variable-reference resolution, and formal behavior checks; Sasaki et al. formalize only within-method Slide Statements [1, 21].Source: §II · p. 3
• Fine-grained moves could relocate only string formatting into updateScoreDisplay while leaving score calculation outside, but such partial-computation refactorings are not automated and are risky manually.Source: §II · p. 3

III. DEFINING FINE-GRAINED MOVE REFACTORINGS

• Five Move Statement variants formalize within-method and cross-method moves; all but Slide Statements are newly formalized, and the framework is iteratively refined against a real project.The formalization also derives additional refactorings by composing Move Statement with existing operations.Source: §III · p. 3
• At the expression level, the paper addresses three Move Expression refactorings and newly defines Move with Holes, which leaves marked subexpressions in the source method.Extract Local Variable and Extract Parameter are based on existing operations; Move Expression from Parameter is new.Source: §III · p. 3

A. Considerations on Behavior Preservation

• Behavior preservation means unchanged return values and side effects for externally called methods on any input; four conditions cover data reachability, execution counts, side effects, and compilation constraints.The framework statically checks BC1, BC2, and BC4, while leaving BC3 to developer judgment.Source: A. Considerations on Behavior… · pp. 3–4
• The claim that BC1–4 preserve behavior is an informal soundness sketch, not a formal proof, and does not exhaustively model concurrency, reflection, argument evaluation order, or exception scopes.The authors instead use iterative refinement and evaluation on real projects to expose the formalization to syntactic diversity.Source: §III · p. 3, A. Considerations on Behavior… · p. 4
• BC1 requires moved statements to reference the same data before and after the move, with operation-specific preconditions and transformations preserving access to that data.For MS→Inv, a variable defined in the moved statements must be used only there or in the target call’s arguments; local variables may be added to callee parameters.Source: A. Considerations on Behavior… · p. 4
• BC2 conservatively requires the target method to be called only once in the source method and nowhere else, and moved statements not to jump outside the set.This can reject safe moves; Extract Local Variable is applied when a data-reference adjustment could change an expression’s execution count.Source: A. Considerations on Behavior… · p. 4
• BC3 requires side effects to be location-independent and the order of interacting side effects to remain unchanged, but the formalization leaves this judgment to developers.The authors assume minor changes such as stack-trace contents or debug-log order may be acceptable rather than enforcing a complete static ordering check.Source: A. Considerations on Behavior… · pp. 4–5
• BC4 prevents syntactic or structural violations that would stop compilation, including unchecked handling of checked exceptions and invalid final or definite-assignment rules.Visibility changes can restore data reachability but weaken encapsulation; the current steps raise visibility directly to public.Source: A. Considerations on Behavior… · p. 5

B. Formalization

• MS→Inv moves a set of consecutive statements from one method to the beginning of the immediately invoked target method, preserving their order.The operation is framed as adjusting method boundaries toward more optimal responsibility assignment.Source: B. Formalization · p. 5
• The moved statements must immediately precede the target call, which must occur only once in the source method and nowhere else, target a method with a body, and contain no jump outside the moved set.These conditions enforce the operation’s definition and execution-count and compilation constraints.Source: B. Formalization · p. 5
• A variable defined in the moved statements may be used only within those statements or as an actual argument to the target call.This restriction supports data reachability across the method boundary.Source: B. Formalization · p. 5
• The move adjusts parameters and receiver references: it removes parameters made unnecessary by moved definitions, passes required receivers and locals, and redirects references through the target receiver or added parameters.The formal steps also introduce local declarations when a removed actual argument is not a direct variable reference.Source: B. Formalization · p. 5
• The move raises visibility for used methods, fields, or classes inaccessible from the target class, and adds missing imports for referenced classes in other packages.Raising a nested class’s visibility also raises the visibility of its enclosing classes.Source: B. Formalization · p. 5
• MS→Ret inserts statements at every target-method exit, while MS← inserts them at calls to the source method and substitutes actual arguments for parameter references.MS→Ret may require a call-result variable when the moved statements use the result; MS← requires call sites to be expression or variable-declaration statements directly inside a block, and MS←Ret additionally limits the source method to one tail return and the moved statements to using only its returned variable. Uniform conditions and constructor- and lambda-related restrictions are also cataloged.Source: B. Formalization · p. 5

C. Iterative Refinement

• The initial formalization mainly covered BC1 and BC2, not BC4’s full syntactic and structural constraints; exhaustive behavior-preserving coverage of every Java-construct combination was deemed impractical.The authors therefore refined the formalization iteratively against a real project.Source: C. Iterative Refinement · pp. 5–6
• On Mockito, the refinement loop applied each of four Move Statement operations to eligible statement–method pairs, compiled the project, ran tests, and analyzed failures until none remained or residual failures were out of scope.The loop treated failures from project-specific tooling as potentially out of scope.Source: C. Iterative Refinement · p. 6
• Three guidelines yielded twenty added preconditions and steps: reject uncompilable or rare constructs, but handle common rewritable constructs in the refactoring procedure.Examples include rejecting assignments to final fields and varargs references, while propagating checked exceptions by adding throws at the destination method.Source: C. Iterative Refinement · p. 6, Table I · p. 6
• 96.3%–98.8% compilation success across the four refined operations on Mockito; tests passed for 132 of 160 (MS→Inv), 131 of 165 (MS→Ret), 431 of 571 (MS←Inv), and 207 of 409 (MS←Ret) applications.Residual compilation failures were false positives from build tooling, flaky internal errors, or intrinsic limitations. Non-passing tests appeared dominated by side-effect changes and reordering left to developer judgment under BC3, with the remainder due to compilation failures and documented limitations.Source: C. Iterative Refinement · p. 6, Table II · p. 6

D. Combination with Other Refactorings

• The two compositions are Move Expression, which moves expressions across methods, and Move with Holes, which keeps selected subexpressions in the source method.They build on existing operations to provide finer-grained moves.Source: D. Combination with Other Refactorings · p. 6
• Extract Local Variable moves expressions within a method, while Move Expression from Parameter moves a call argument into the callee and Extract Parameter moves an expression back to the call site.Move Expression from Parameter extracts the expression before applying MS→Inv; preconditions for both constituent operations are checked in sequence.Source: D. Combination with Other Refactorings · p. 6
• Move with Holes lets users mark subexpressions to remain in the source by extracting each Hole, applying MS→ or ME→, then inlining each extracted variable.This yields more flexible moves while reusing existing preconditions.Source: D. Combination with Other Refactorings · p. 6

IV. TOOL SUPPORT

• The plugin implements the formalized refactorings in IntelliJ IDEA, using PSI for syntactic and dataflow analyses and formatting-preserving code rewrites.It checks preconditions and applies refactoring steps on the PSI.Source: §IV · pp. 6–7
• Drag-and-Drop Refactoring lets developers invoke moves by dragging program elements to targets, with drop targets highlighted when static preconditions hold.Table III maps each refactoring to its drag source and drop target; Fig. 7 illustrates dragging a statement onto a target-method call for MS→Inv.Source: §IV · p. 7, Figure 7 · p. 7, Table III · p. 7
• On drop, the plugin automatically checks static preconditions and either applies the refactoring with those conditions satisfied or rejects it without changing the code.The current interface does not warn about potential side-effect reordering; surfacing the developer-checked BC3 condition and evaluating interface usability with developers are future work.Source: §IV · p. 7

V. EVALUATION

• The evaluation asks whether Move Statement refactorings apply to statements, whether transformed code compiles, what behavioral changes remain after compilation, and whether combined refactorings expand applicability.The evaluation assesses applicability and behavior preservation of the newly formalized refactorings.Source: §V · p. 7
• The evaluation covered ten Defects4J projects, following prior refactoring evaluations, with 67,509 methods overall; mockito and six projects that could not be built with JPS were excluded.The selected projects ranged from 1,043 methods in commons-cli to 11,700 in jfreechart; detailed data are in the supplemental package.Source: §V · p. 7

A. RQ1: Applicability

• Of 67,509 methods, 9,077 (13.4%) met MS→ conditions, 17,385 (25.8%) met MS←Inv conditions, and 14,557 (21.6%) met MS←Ret conditions.MS→ requires a target called exactly once with a body; MS←Inv requires all source call sites to be variable declarations or expression statements; MS←Ret additionally permits at most one tail return.Source: A. RQ1: Applicability · p. 7
• For each operation, the evaluation enumerated candidate statement–method pairs, tested whether SS could move each statement to a method boundary, and checked cross-method preconditions.Table IV reports the resulting totals.Source: A. RQ1: Applicability · p. 7, Table IV · p. 8
• 2,654 (MS→Ret) to 13,825 (MS←Inv) instances were applicable, providing an upper bound on moves satisfying statically checked preconditions; design improvement remains a separate question.For all but MS→Ret, same-method reordering (SS) is the dominant constraint.Source: Table IV · p. 8, A. RQ1: Applicability · p. 8
• Only 24.5–30.8% of candidate statements could be reordered to a method boundary, while 23.1–77.7% of those passing SS met cross-method preconditions.Except for MS→Ret, SS retained a smaller fraction of candidates than the cross-method preconditions.Source: A. RQ1: Applicability · p. 8

B. RQ2: Compile Correctness

• Table V reports the totals: across all four operations, compile success rate was 93.3–97.0%, and per-project rates ranged from 85.3% to 100%.Source: B. RQ2: Compile Correctness · p. 8
• The authors manually mapped each compilation failure to its root violated basic condition and classified its cause as a defect, limitation, infrastructure failure, or missing precondition.Compile success is a meaningful first-line check because 67.2% of refactoring-engine bugs manifest as compilation errors or crashes, but it is only necessary—not sufficient—for behavior preservation.Source: B. RQ2: Compile Correctness · p. 8
• All individual causes with more than 100 occurrences violated BC1, making data reachability the dominant residual concern; BC4 violations were individually rare but collectively justified a separate condition.Override-visibility failures were concentrated in one project: 68 of 69 MS→Inv and 114 of 114 MS→Ret occurrences were in commons-compress.Source: B. RQ2: Compile Correctness · p. 8
• Implementation defects caused 467 of 1,263 failures, missing preconditions 329, documented limitations 288, and infrastructure failures 43; 61 engine crashes were tool defects.The remaining 136 failures were spread across infrequent diagnostic families.Source: B. RQ2: Compile Correctness · p. 8
• Three high-impact BC1 problems were override breakage after visibility widening, duplicate declarations after moving between disjoint scopes, and broken calls when rename logic also renamed a method reference.The disjoint-scope case lacks a scope-overlap precondition; the rename case can turn iterator() into iterator1() when iterator is renamed iterator1.Source: B. RQ2: Compile Correctness · p. 8

C. RQ3: Behavior Preservation: Case Study on commons-cli

• The test-suite case study was limited to commons-cli (n=1), so its pass rates describe this project and do not estimate population-level behavior.Testing every applicable instance across all ten projects was prohibitively expensive; the case study characterizes failure modes that compilation cannot expose.Source: C. RQ3: Behavior Preservation: Case… · p. 9
• 26.8% was the MS→Inv test pass rate, reflecting BC3’s design decision to leave side-effect ordering to developer judgment rather than a defect in static checks.The case study found no observed behavioral changes attributable to defects in BC1, BC2, or BC4.Source: C. RQ3: Behavior Preservation: Case… · p. 9
• After excluding compile failures and implementation limitations, all observed behavioral changes stemmed from side effects and their ordering, not defects in statically checked conditions.The identified causes included reordering of side effects induced by SS and side-effect changes from cross-method moves, especially MS← when the source method may be called multiple times.Source: C. RQ3: Behavior Preservation: Case… · p. 9

D. RQ4: Applicability of the Combined Refactorings

• 72.6% of MS→-applicable instances support Move with Holes; ME→ applies to 1,107 instances, and Move with Holes applies to 17.6% of ME→ instances.ME→ has fewer applicable instances because it inherits MS→’s single-call-site requirement and restricts argument shape; within ME→, arguments rarely contain another extractable expression.Source: D. RQ4: Applicability of the Combined… · p. 9

1) Construct Validity:

• Compilation success and test pass rates may miss semantic deviations such as aliasing-related value changes, and existing project tests exercise refactored code less thoroughly than generated tests targeting changed methods.The study reuses existing test suites rather than the more systematic test-generation approach described by Soares et al..Source: 1) Construct Validity · p. 9
• Treating stack-trace differences as tolerable is an assumption, and stricter standards could reduce counted successes; applicability counts do not assess whether individual moves are desirable.The discussion cites Liu et al. on developers not always preserving behavior strictly, and places design-level assessment through cohesion metrics or developer studies outside scope.Source: 1) Construct Validity · p. 9

2) Internal Validity:

• The precondition and application-step formalization may contain flaws, and implementation bugs could make the evaluated tool diverge from it and distort outcomes.Source: 2) Internal Validity · pp. 9–10
• Latent defects may not surface as compilation errors, while the RQ3 failure-cause analysis may include misclassifications from manual inspection.The study classified RQ2 compilation failures and mapped them to basic conditions; RQ3 causes were inspected manually by the authors.Source: 2) Internal Validity · p. 10

3) External Validity:

• The evaluation covers ten open-source Java projects, but single-project refinement and a qualitative case study limit generalization across coding styles, project sizes, domains, and languages.Mockito compile success was 96.3–98.8%, compared with 93.3–97.0% on evaluation projects; broader test-based evaluation was deferred because of runtime constraints.Source: 3) External Validity · p. 10

VI. RELATED WORK

• Whole-program remodularization uses class and method moves to redistribute responsibilities, but its thousands of scattered changes can impede adoption; this work instead targets localized, incremental moves.Prior approaches include metaheuristic search such as NSGA-III, harmony search, and ant colony optimization.Source: §VI · p. 10
• Move Method recommenders use relationships, dependency similarity, learned representations, or LLM-assisted tools,, but cannot shift method boundaries by moving statements or expressions.Examples include distance- and dependency-based methods,, attribute, invocation, and concept relationships, JMove, and learned approaches,.Source: §VI · p. 10
• Fowler cataloged statement moves, while Sasaki et al. formalized within-method reordering; that work neither crosses method boundaries nor accounts for resulting compilability.Sasaki et al. use Def-Use, Def-Def, and Escape constraints to preserve data and control-flow properties.Source: §VI · p. 10

VII. CONCLUSIONS AND FUTURE WORK

• Across ten Defects4J projects, 93.3–97.0% of applied cases compile successfully; the formalization covers five Move Statement and three Move Expression variants, and case-study changes arose from BC3 side-effect reordering.The formalization grounds preconditions and steps in data reachability, execution count, side effects, and syntactic constraints; twenty additional rules address Java syntax in practice.Source: §VII · p. 10
• Future work would extend operations to methods with multiple call sites and measure the prevalence of excluded constructs such as concurrency and reflection.The proposed payoff bound counts rejected moves carrying identical statements at every call site.Source: §VII · p. 10
• Future evaluation would refine and test on more projects, ablate the twenty refinement rules, and compare with IDE-refactoring compositions, LLM edits, and commit-history moves.Source: §VII · p. 10
• Future developer-facing work would recommend which statements to move and where, then evaluate the drag-and-drop interface with developers.Source: §VII · p. 10