What does semantic refactoring look like?

Tyler Van Gorder
|
March 21, 2022
Moderne Engineering
Contents

Key Takeaways

I think I could make a relatively safe bet that most software developers have some form of a semantic refactoring tool installed on their machine right now. Have you ever used your IDE to move a variable, rename a method, or move a class to a different namespace? Congratulations, you have used semantic search and replace.

Semantic Refactoring Is All About Context

An IDE is able to make these "smart" changes because the editor is informed by the tools that are used to compile the code. The source code that you view in the editor has additional semantic information that is not represented in the syntax but implied by way of linking to an external library or a different type within the project.

To illustrate the difference consider how the same source file would be interpreted with a syntactically aware editor such as Sublime Text. The editor would provide syntax highlighting but would not provide feedback that the source file compiles in the context of the larger project.

The refactoring capabilities of a modern IDE are a productivity multiplier for a developer when they are making large-scale changes to their project when compared with using a tool that does not provide semantic information.

Composable Semantic Refactoring

Have you ever been tasked with migrating to a new, major version of a third-party library that is used within your project?

You can't really use the refactoring capabilities of the IDE because the semantic information for the old version has been replaced by the new version!

This type of refactoring requires a new class of tools (Hi OpenRewrite!) that can use the semantic information from both versions of the software to perform the task at hand. Additionally, if you had semantic information for the build file that expresses the dependencies for your project, you could add an additional step that modifies the build file to use the new version of the dependency.