Refactoring Spaghetti Code: How Bad Formatting Hides Bugs

Refactoring Spaghetti Code: How Bad Formatting Hides Bugs

“Spaghetti Code.” I was working on one of the project where the code was written by some junior devs and that too it was old code.

Problem was that it was giving errors when I saw the code it was actually one of the curly braces not pointing to proper else we call it as dangling else problem.

I manage to fix it but the problem is not about what is the issue. Problem was not doing or adding any proper indentation because of which that else was pointing and misleading.

Another case in the same project is that there are if conditions without having any opening and closing curly braces so the issue came because it was terminating after the first scenence and one of the dev wrote condition based for 2 lines and in this whole case he almost spend a day or two still he was not able to figure out what is the error and why his code is not producing the expected results.

So all such type of scenarios makes code that is difficult to read, understand, and maintain, So we call all these cases as “Spaghetti Code“

The term summons images of tangled logic, methods that are 500 lines long, and variable names like temp1, temp2, and flag.

But as a consultant who has spent years rescuing legacy Java projects, I’ve learned a secret: Half of the problem isn’t the logic. It’s the formatting.

When we talk about “Legacy Code,” we often think of old versions of Java (like Java 5 or 6). But modern code can be “legacy” the moment it is written if it is unreadable. In this post, we are going to look at how poor indentation camouflages critical bugs and why the first step in any refactoring job should always be “Select All > Format.”

The Visual Lie: When Indentation Lies to You

Our brains rely on visual patterns. In Python, indentation is the logic. In Java, indentation is optional, but our brains treat it like logic.

Consider this classic bug, known as the “Dangling Else” problem:

// BAD CODE
if (isUserLoggedIn)
    if (hasPremiumAccess)
        showPremiumContent();
else
    redirectToLogin();

Look at that code quickly. It looks like the else belongs to the first if (isUserLoggedIn). Visually, the indentation tells you: “If the user is NOT logged in, redirect them.”

This is a lie.

The Java compiler ignores your whitespace. It pairs that else with the nearest if statement—the hasPremiumAccess check.

So the actual logic is: “If the user IS logged in, but does NOT have premium access, redirect them to login.” If the user is NOT logged in, the code does nothing.

This is a critical security bug hidden in plain sight by bad formatting.

The “Format First” Strategy

Whenever I inherit a messy class file, I do not try to read it. I do not try to understand the business logic.

I immediately run it through a strict Java Formatter.

Why? Because I need to align the Visual Truth with the Logical Truth.

If I take that same buggy code snippet above and paste it into the Toolshref Java Formatter, here is what comes out:

// FORMATTED CODE
if (isUserLoggedIn)
    if (hasPremiumAccess)
        showPremiumContent();
    else
        redirectToLogin();

Suddenly, the bug is obvious. The else is indented under the second if. I can see the visual hierarchy immediately. I didn’t need to run a debugger or write a unit test to find this. I just needed to format the code.

Visualizing Nested Hell

Legacy code is famous for the “Arrow Anti-Pattern”—code that looks like an arrow because it is indented so deep.

for (User u : users) {
  if (u.isActive()) {
    try {
      if (u.hasOrders()) {
        // ... logic ...
      }
    } catch (Exception e) {
      // ...
    }
  }
}

When you are 6 levels deep, it is impossible to know which closing brace } matches which opening brace {.

If the previous developer wasn’t strict about their indentation, you might accidentally delete a brace that closes the try block when you meant to close the if block.

By using a tool to Force-Format the braces (especially using the “Expanded” brace style where braces get their own line), you create a visual map. You can draw a line with a ruler from the top brace to the bottom brace.

Summary: Cleaning Before Repairing

Imagine you are a mechanic. A car comes in covered in mud. You don’t start taking the engine apart immediately. You wash the car first. Why? Because you can’t see the cracks in the engine block if it’s covered in dirt.

Bad formatting is the “mud” of software engineering.

Before you try to fix a bug, refactor a method, or optimize a loop, clean the code. Use our Java Formatter to strip away the visual lies. Once the structure is honest, the bugs often reveal themselves.

FAQ Refactoring Spaghetti Code