Integrating Structural and Semantic Analysis for Code Smell Refactoring Prediction

Software is never truly finished. Like a city that grows organically over decades, a computer program accumulates layers of additions, patches, and quick fixes. Over time, this organic growth can lead to structural weaknesses, much like a building where a hallway has been widened without reinforcing the walls. In the world of software engineering, these localized flaws are known as "code smells." They are not errors that cause a program to crash, but rather signs of poor design that make the code difficult to understand, change, or maintain. When developers spot these smells, they often perform "refactoring," a careful process of reorganizing the code to improve its structure without changing what the software actually does. The challenge is that developers do not always fix every smell they find, and predicting which ones will be fixed is difficult because the decision often depends on human intent and context, not just the code itself.

A team of researchers at the University of Milano-Bicocca set out to see if machines could learn to predict these human decisions. They wanted to know if a computer could look at a piece of code, identify a flaw, and accurately guess whether a developer would eventually clean it up. To do this, they built a system that combines two different ways of looking at code. The first way is traditional: counting properties like how long a method is or how many variables it uses. The second way is more modern and complex: turning the code into a map of its logic and behavior, then translating that map into a mathematical representation that a computer can analyze for hidden patterns. By feeding this combined information into machine learning models, the researchers tested whether the computers could learn the subtle rules that guide developers when they choose to refactor.

The researchers gathered data from 79 open-source Java projects, a collection of software that had been developed and maintained by many different people over time. They used automated tools to scan the history of these projects, identifying thousands of instances where code smells were present and tracking which ones were later fixed through specific refactoring actions, such as renaming a variable, extracting a method into a smaller piece, or changing a parameter. They then created a hybrid dataset for each piece of code. This dataset included standard measurements, like the number of lines in a method, alongside two different types of "embeddings." One type of embedding mapped the flow of control, showing the order in which instructions execute. The other, more advanced type, mapped the deeper semantic relationships, capturing how data moves through the program and how different parts of the code depend on one another, effectively creating a rich, multi-dimensional portrait of the code's behavior.

The results showed that machine learning models are indeed capable of predicting refactoring with a high degree of reliability. When the models were tested on ten different types of refactoring operations, they frequently achieved AUC scores well above 0.70, and for some tasks, they surpassed 0.80. This suggests that there are indeed detectable patterns in the code that signal a developer's intent to clean it up. However, the study revealed a crucial nuance: not all code smells are created equal. The models were exceptionally good at predicting structural changes, such as adding a parameter to a method or changing a variable's type. These actions are often driven by clear, measurable factors like the length of a statement or the complexity of a calculation. In contrast, the models struggled to predict more conceptual changes, such as renaming a method. Renaming is often a subjective decision based on how a developer thinks about the code's purpose, a factor that is difficult to capture with numbers or structural maps alone.

Perhaps the most significant finding concerned the type of data representation used. The researchers initially expected that simply adding more complex maps of the code's execution flow would improve the predictions. Instead, they discovered that a specific type of flow map, which tracked the order of statements, actually introduced noise that confused the models. When this flow map was combined with the traditional measurements, it often made the predictions worse, as the computer struggled to ignore the irrelevant details. However, when the researchers switched to the more advanced representation that combined structural dependencies with the actual text and logic of the code, the results changed dramatically. This richer representation provided a complementary signal that the models could use effectively. In fact, for some tasks, the models trained solely on this advanced representation performed nearly as well as those trained on the full dataset, proving that the deep structural and semantic understanding of the code was a powerful predictor in its own right.

The study also highlighted the limits of what can be predicted from code alone. While the models could reliably forecast technical fixes driven by complexity, they could not easily foresee the human decisions behind renaming or reorganizing code for clarity. This suggests that while machines can be excellent at identifying when a piece of software is technically overdue for maintenance, the final decision to refactor often relies on a developer's vision and context that exists outside the code itself. The research concludes that the future of automated software maintenance lies not in replacing human judgment, but in using these predictive tools to highlight the structural debts that are most urgent, allowing developers to focus their limited time on the changes that matter most. By understanding which signals are strong and which are noise, we can build better tools to help keep our digital infrastructure healthy and sustainable.