Read Someone Else's Messy Code: Format First, Understand Second

You inherit a file that looks like it was typed by someone holding the keyboard upside down in a hurry. Half the blocks aren't indented, closing braces sit wherever they landed, and a function that should take ten seconds to scan takes ten minutes. Your first instinct is to understand it before touching anything. That instinct is backwards. Format the code first, then read it — structure turns confusion into something you can actually follow. It sounds like putting off the hard part, but it's the fastest way in.

Indentation Is Information

Badly formatted code hides its own shape. When indentation is missing or inconsistent, you can't see what nests inside what, and nesting is most of what you're trying to understand. Run the file through a code formatter and the structure snaps into view: which block belongs to which condition, where the loop ends, which function is inside which. The counter-intuitive part is that formatting makes the code easier to read without changing what it does — a formatter that touches only whitespace can't alter behavior, which is exactly why it's safe to run on a file you don't understand yet.

Format as a Reading Aid, Not a Style Debate

This isn't about winning a style argument. If the team uses a different indentation style, you can reformat again later; the point right now is comprehension, not convention. The same trick scales to the data the code works with. When the file is full of nested JSON — configs, API fixtures, test data — run that through a JSON formatter too, so you're reading cleanly nested structures instead of one long line. And when the messy file turns out to be HTML docs you need to understand, a HTML to Markdown pass strips the markup noise and leaves readable content. Format every layer before you read any layer.

The Clean-Up That Pays for Itself

There's a version of this for whole codebases too, which we covered in our guide to formatting legacy projects without breaking them. The habit is always the same: structure first, understanding second, changes third. Start with the file that scares you most and run it through the formatter; ten minutes of structure now saves an hour of squinting later. You'll read the file once clean instead of three times squinting, and you'll make your first real edit knowing what the code actually does — which is the whole point.