Detecting Object-Oriented Code Smells through Social Network Analysis
This paper proposes a novel approach to detecting object-oriented code smells by modeling software components and their interactions as social networks and applying Social Network Analysis (SNA) metrics to four Java open-source projects to uncover hidden design flaws.
Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Software is built from countless small instructions that work together, much like a city is built from individual buildings and the roads connecting them. When a city is well-planned, traffic flows smoothly, and new neighborhoods can be added without chaos. In the world of computer programming, this organization is called "object-oriented design," where code is grouped into self-contained units that interact with one another. However, just as a city can suffer from overcrowded intersections or abandoned buildings, software can develop structural flaws known as "code smells." These are not errors that cause a program to crash, but rather signs that the design is becoming messy, difficult to understand, or hard to fix. Left unchecked, these smells make software fragile and expensive to maintain, forcing developers to spend more time untangling knots than building new features.
For decades, researchers have tried to find these flaws automatically, often by counting lines of code or measuring how many variables a single section uses. While helpful, these traditional methods sometimes miss the bigger picture, failing to see how different parts of the system rely on each other in complex ways. A new approach, detailed in a recent study by Mohamed Maddeh of King Saud University, suggests looking at software not just as a collection of files, but as a social network. In this view, every class of code is a person, and every time one piece of code uses another, it is a social interaction. By applying the same mathematical tools used to map friendships and influence in human communities, the researcher developed a way to spot these structural weaknesses with greater clarity.
The study focused on four well-known, open-source software projects written in the Java language: JUnit, Spring, Apache Commons BCEL, and Guava. These projects vary significantly in size, ranging from a few hundred to over four thousand distinct code units. To analyze them, the researcher first extracted every class within these projects and mapped out exactly how they interacted. If one class needed data or a function from another, a line was drawn between them, creating a massive web of connections. This web was then imported into a specialized visualization tool called Gephi, which allowed the researcher to see the entire structure of the software as a single, interconnected map.
Once the software was modeled as a network, the researcher applied specific measurements to identify the "smells." In a social network, a person who knows everyone else and sits at the center of many conversations is highly connected. In software, a class that interacts with too many other classes often indicates a "God Class," a unit that has taken on too many responsibilities and is trying to do everything. Conversely, a person who knows no one and sits alone on the edge of the map represents "Dead Code," a piece of software that is no longer used. Other patterns, such as a group of people who only talk to each other but never to the outside world, or a single person who acts as the only bridge between two separate groups, revealed flaws like "Data Classes" that hold information without doing anything, or "Shotgun Surgery," where a single change requires modifications in many different places.
The results showed that this network-based method could effectively filter out the vast majority of code that was healthy, leaving developers with a much smaller list of suspects to inspect. In the largest project studied, which contained over four thousand classes, the method flagged only about 17 percent as potentially problematic. In another project with nearly a thousand classes, it identified roughly 35 percent as needing attention. The visualization tools made these findings immediate and intuitive; the "God Classes" appeared as large, brightly colored hubs in the center of the map, while the "Dead Code" and "unused classes" appeared as small, dim nodes pushed to the very edges, often isolated in their own disconnected islands.
This approach does not claim to replace human judgment or to perfectly identify every single flaw without error. Instead, it serves as a powerful triage tool, a way to reduce the overwhelming task of reviewing an entire codebase down to a manageable list of the most structurally unusual parts. By focusing on the relationships between pieces of code rather than just their internal content, the method offers a fresh perspective on an old problem. It suggests that the health of a software system is often visible in the pattern of its connections, and that by mapping these patterns, developers can find the hidden weaknesses that threaten the stability of their digital creations before they become unmanageable.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.