PaperlayerView exact revision on arXiv

Source-linked AI summary

Formalizing and Automating Fine-Grained Move Refactorings Across Methods

Kota Yasuhara, Shinpei Hayashi

arXiv:2608.23377v1cs.SE

TL;DR

Statement- and expression-level moves remain largely unautomated despite their value for adjusting method boundaries and responsibilities. The paper formalizes these moves with static preconditions and automated steps, refines them against real Java code, and evaluates them across projects. Applied cases compile successfully in 93.3–97.0%, while the case study attributes behavioral changes to side-effect reordering left to developers.

  • Problem

    Statement- and expression-level moves remain largely unautomated, although they can improve method boundaries and responsibility assignments.

  • Method

    The paper formalizes Move Statement and Move Expression refactorings through preconditions and automated steps grounded in four behavior-preservation conditions.

  • Results

    93.3–97.0% of applied refactoring cases compile successfully across ten projects.

  • Takeaways & Limitations

    The approach supports automated, statically checked mechanics while leaving side-effect reordering to developer judgment.

  • Takeaways & Limitations

    The evaluation is limited by project scope, single-project refinement and case-study design, with broader testing left for future work.

Abstract

from arXiv · show

Developers use automated Move refactorings to improve the modular structure of source code and the assignment of responsibilities. Class- and method-level Move refactorings are automated in modern IDEs, but statement- and expression-level moves that adjust method boundaries remain largely unautomated. We formalize five variants of Move Statement refactoring as preconditions and steps grounded in four basic conditions covering data reachability, execution count, side effects, and syntactic constraints required for compilation, of which all but the side-effect condition are checked statically. Combined with existing techniques, this also yields finer-grained moves of expressions and partial expressions. We further refine the formalization iteratively against a real project, deriving twenty additional preconditions and steps that handle Java syntactic diversity in practice. We evaluate applicability and compilability on ten projects, and behavior preservation in a case study on one of them: Move Statement refactorings yield compilable code in 93.3-97.0% of applicable cases, and the case study shows that the observed behavioral changes stem from side-effect reordering left to developer judgment, not from defects in the statically checked conditions.

I. INTRODUCTION

Fine-grained moves can improve method boundaries and responsibility assignments, but statement- and expression-level refactorings remain insufficiently formalized and automated. This paper addresses that gap with formal conditions, iterative refinement, and empirical evaluation.

  • Motivation: Statement- and expression-level moves let developers redefine method boundaries and balance responsibility assignments beyond method-level class-boundary changes.Localize Parameter is reported 31.56 times per project on average, indicating practical demand for these refactorings.
  • Research gap: Existing catalogs lack the precise preconditions and transformation steps needed for automated, behavior-preserving moves across methods.Prior same-method formalization cannot move statements across methods, and expression moves lack systematic treatment.
  • Approach: The paper formalizes fine-grained moves using four conditions covering data reachability, execution count, side effects, and compilation constraints.All conditions except side effects are checked statically, while side-effect reordering remains for developer judgment.
  • Approach: An iterative refinement methodology adds twenty preconditions or steps based on failures observed in a real project.The resulting rules address Java syntactic diversity in practical code.
  • Evaluation: Across ten projects, the evaluation reports compile success rates of 93.3–97.0% for applied refactorings.The study also examines applicability, test-based behavior preservation, and compile-failure causes.

II. MOTIVATION

Examples motivate fine-grained moves by showing both responsibility improvements and risks to behavior or compilation. Existing informal definitions and limited formalizations do not provide sufficient automation support.

  • Motivating examples: Moving a call from a callee to its caller can preserve behavior when the callee has only that caller.The dbeaver example moves addObjectExtraActions from addStructObjectCreateActions to getPersistActions.
  • Motivating examples: Manual cross-method moves require resolving references such as replacing a callee-local argument with this at the caller.Without automation, developers must perform this reference adaptation themselves.
  • Motivating examples: Moving a print statement across an assignment changes the observed value of isLogin from true to false.The example demonstrates that statement placement can alter observable behavior through execution-order changes.
  • Refactoring scope: Move Statement variants adjust method boundaries by moving code into methods, to callers, or within the same method.Slide Statements improves locality, while cross-method variants alter responsibility assignments at statement granularity.
  • Research gap: Fowler’s definitions provide neither automated preconditions nor mechanisms for cross-method variable-reference resolution.The prior same-method formalization targets only Slide Statements, and behavior equivalence was checked by trial-and-error tests.
  • Expression-level motivation: Partial computations can also be moved, such as placing string formatting inside updateScoreDisplay while retaining score calculation outside.This motivates expression-level refactorings that refine responsibility assignment within a statement.

III. DEFINING FINE-GRAINED MOVE REFACTORINGS

The paper defines five Move Statement variants and three Move Expression variants, including new cross-method and partial-expression operations. Their formalization is refined iteratively to handle practical Java syntax.

  • Move Statement variants: The formalization derives Move Statement catalog entries from Fowler’s definitions and refines them against a real project.The process adds practical preconditions and transformation steps beyond the initial catalog.
  • Move Statement variants: MS→Inv and MS→Ret move statements to the beginning or end of a callee method, while MS←Inv and MS←Ret move them around a caller’s method call.All variants except Slide Statements are newly formalized in this paper.
  • Move Expression variants: Expression-level refactorings correspond to existing operations for local extraction and parameter extraction, plus a new Move Expression from Parameter operation.These operations extend the Move Statement concept to expressions.
  • Move with Holes: Move with Holes keeps developer-marked subexpressions in the source method while moving the remaining expression or statement.The operation applies to MS→ and ME→.

A. Considerations on Behavior Preservation

The formalization frames behavior preservation around four conditions: unchanged data references, execution counts, side effects and their ordering, and compilation-valid syntax. BC1, BC2, and BC4 are checked statically, while side-effect ordering remains for developer judgment.

  • Behavior preservation means externally called methods retain the same return value and side effects for any input after refactoring.
  • MS→Inv moves selected statements to the beginning of the called method while preserving their order.
  • BC1 requires moved statements to reference the same data before and after the move, including through call arguments.
  • BC2 preserves execution counts, while conservative conditions restrict the target call to one occurrence and prohibit jumps outside the moved statements.
  • BC3 preserves individual side effects and the order of interacting side effects, but side-effect checking is deliberately left to developers.
  • BC4 prevents compilation failures by enforcing syntactic and structural constraints, including exception handling, assignment rules, and valid class structure.

B. Formalization

The formalization specifies MS→Inv as a catalog entry with named inputs, preconditions, and transformation steps for moving consecutive statements across a method invocation.

  • MS→Inv means Move Statements into Method beyond Invocation, moving consecutive statements to the beginning of the target method in order.
  • The refactoring requires the selected statements to be consecutive and immediately followed by the target-method call.
  • The target method must be called once from the source method, nowhere else, and must have a concrete body.
  • No moved statement may jump outside the selected set, and variables defined there may be used only internally or as target-call arguments.

C. Iterative Refinement

The authors refine the initial formalization against mockito by compiling and testing every applicable move, then converting observed failures into preconditions or transformation steps.

  • The initial formalization mainly covered data references and execution counts, leaving syntactic and structural constraints incompletely addressed.
  • The refinement loop enumerates applicable statement–method pairs, applies each move automatically, compiles the project, runs tests, and analyzes failures.
  • Twenty preconditions and steps were added across the four operations after applying guidelines based on avoidability, practical rarity, and rewriteability.
  • 96.3–98.8% compilation success was achieved across the four operations on mockito after refinement.
  • Test-passing applications were 132 of 160 for MS→Inv, 131 of 165 for MS→Ret, 431 of 571 for MS←Inv, and 207 of 409 for MS←Ret.

D. Combination with Other Refactorings

Combining Move Statement with existing expression refactorings produces moves of expressions and partial expressions, while an IntelliJ IDEA plugin automates the checks and transformations.

  • The compositions target two extensions: moving expressions across methods and excluding selected subexpressions from a move via Holes.
  • Move Expression from Parameter extracts a call argument expression into a local variable, then applies MS→Inv to place it in the callee.
  • Move with Holes extracts marked subexpressions, performs the move, and inlines the extracted variables afterward.
  • The implementation is an IntelliJ IDEA plugin that checks preconditions and rewrites code through the Program Structure Interface.
  • Drag-and-Drop Refactoring invokes a move by dragging a program element onto its target, including dragging a statement onto a target-method call for MS→Inv.

V. EVALUATION

The evaluation measures applicability across ten Defects4J projects and finds thousands of statically applicable Move Statement instances. Same-method statement reordering is the dominant constraint for most operations.

  • The evaluation covers applicability, compilation, behavioral changes, and combined-refactoring range across ten Defects4J projects.The projects contain 67,509 methods in total.
  • Applicability: 13.4% of methods satisfy MS→, 25.8% satisfy MS←Inv, and 21.6% satisfy MS←Ret conditions.These percentages correspond to 9,077, 17,385, and 14,557 methods, respectively.
  • Applicability: 2,654–13,825 applicable instances are identified across Move Statement operations.The range extends from 2,654 for MS→Ret to 13,825 for MS←Inv.
  • Applicability: 24.5–30.8% of candidate statements pass same-method reordering, while 23.1–77.7% of those passing it satisfy cross-method preconditions.Except for MS→Ret, same-method reordering retains a smaller fraction than the cross-method conditions.
  • Applicability: Same-method reordering is the dominant constraint for all operations except MS→Ret.The evaluation treats applicable instances as those satisfying all statically checked preconditions.

B. RQ2: Compile Correctness

Compilation is used as a first-line check of the automated refactorings, while failures are classified by violated conditions and cause classes. Across operations, most applied instances compile, but residual failures include defects, missing preconditions, limitations, and infrastructure problems.

  • Compile success is a necessary but not sufficient condition for behavior preservation.The evaluation applies each refactoring to a source-tree copy and records whether the result compiles.
  • 93.3–97.0% of applied instances compile across all four Move Statement operations.Per-project compile-success rates range from 85.3% to 100%.
  • Failure analysis: Data reachability is the dominant residual concern because all individual causes occurring more than 100 times are BC1 violations.BC4 violations are individually rare but motivate a separate condition for compilation-related cases.
  • Failure analysis: 467 of 1,263 compilation failures are implementation defects, 329 are missing preconditions, 288 are documented limitations, and 43 are infrastructure failures.The 61 engine crashes are classified as tool defects rather than formalization gaps.
  • Failure analysis: Visibility-induced override breakage, variable double-definition, and rename-induced reference breakage remain high-impact failure examples.The latter two expose a missing scope-overlap precondition and a name-clash implementation defect, respectively.

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

A commons-cli case study examines behavioral changes that survive compilation, but its single-project design is descriptive rather than population-level. Excluding compile failures and tool limitations, all observed changes arise from side-effect reordering left to developer judgment.

  • The commons-cli case study runs the project test suite after each successful refactoring application.Testing every applicable instance across all ten projects was prohibitively expensive.
  • Behavioral changes: Side-effect reordering induced by same-method reordering is the dominant failure cause for MS→Inv.An example is individually movable add calls on the same collection whose observable order changes.
  • Behavioral changes: Side-effect changes from cross-method moves are more prominent for MS← because the source method may be called multiple times.These changes are mostly reorderings, with one positional change.
  • Behavioral changes: Aside from compile failures and tool limitations, every observed behavioral change stems from side-effect reordering left to developer judgment.None was traced to a defect in the statically checked conditions.

D. RQ4: Applicability of the Combined Refactorings

The combined expression-level refactorings are applicable in many cases, with Move with Holes broadly applicable on top of MS→ and ME→ applicable at a smaller scale. The evaluation also highlights limitations of proxy-based behavior checks and possible implementation-related validity threats.

  • 72.6% of MS→-applicable instances support Move with Holes.These instances contain non-trivial subexpressions that could remain behind as holes.
  • 1,107 ME→ instances are applicable, fewer than for MS→ because ME→ inherits the single-call-site requirement and restricts argument shape.
  • 17.6% of ME→ instances support Move with Holes.The lower rate reflects the additional requirement for an extractable non-bare-variable subexpression.
  • Applicability counts indicate where refactorings can be applied, not where individual moves are desirable at the design level.Cohesion metrics and developer studies are outside the evaluation scope.
  • Compilation failures may be distorted by implementation bugs, while manual failure-cause inspection may include misclassifications.

3) External Validity:

The paper’s external validity is bounded by its Java and Defects4J focus, single-project refinement, and limited case-study design. It also identifies broader evaluation and recommendation support as future directions.

  • External Validity: Ten open-source Java Defects4J projects provide the evaluation setting, so results may differ on closed-source projects or other domains.
  • External Validity: The single-project refinement may bias preconditions and steps toward mockito’s coding style.The paper reports lower compile success across evaluation projects and commons-compress-specific override-visibility failures.
  • External Validity: The commons-cli case study is a qualitative probe rather than a basis for quantitative generalization, and broader test-based evaluation remains future work.
  • External Validity: Because the formalization targets Java, other languages may require different preconditions and steps due to syntactic and semantic differences.
  • Future Work: Future work includes testing refinement rules on more projects, comparing against IDE, LLM, and commit-history baselines, and recommending developer-facing moves.
Loading 2608.23377v1…