Formalizing and Automating Fine-Grained Move Refactorings Across Methods
2026-08-24 • Software Engineering
Software Engineering
AI summaryⓘ
The authors studied how to move small pieces of code (like statements or expressions) inside methods to make programs better organized. They created formal rules to safely move these pieces without breaking the code, mostly by checking things like data access and syntax before running the program. They tested their rules on real Java projects and found that the moves usually keep the code working and compiling correctly. Any changes in how the program behaves are mostly due to the order of effects that developers need to watch out for. Overall, their work helps automate detailed code rearrangements that previous tools didn't handle well.
Move refactoringAutomated refactoringCode modularityStatic analysisData reachabilitySide effectsSyntax constraintsJava programmingBehavior preservation
Authors
Kota Yasuhara, Shinpei Hayashi
Abstract
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.