Here's a small habit that changed how I do code reviews: I never review unformatted code anymore.
It started when I caught myself spending twenty minutes on a pull request that turned out to have exactly three lines of actual changes. The rest was mixed tabs and spaces, inconsistent brace placement, and one 400-character line that made the diff view wrap into nonsense. I was reviewing formatting, not logic. The author was a good programmer; the code was just messy. And my review was worse because of it — I was tired and irritable by the time I reached the part that mattered.
That was the moment I made a rule: format first, review second.
The routine
Before I read a single line of logic in a PR, the code gets normalized. I paste it into TidyCode, hit format, and copy it back. Ten seconds, maybe fifteen for a big file. The result is a diff that shows only real changes, and a review where my brain spends its budget on what the code does instead of how it looks.
This works in both directions. When I'm the one submitting, I run the same pass before pushing. My PRs got noticeably easier to review — reviewers respond faster to clean diffs, not because they're judging style, but because clean code is simply cheaper to read. Fewer "can you fix the indentation here" comments, more comments about actual design decisions.
Why a browser tool fits this habit
I deliberately don't use an installed formatter for this. It's a ten-second task I do a few times a day, often on machines that aren't mine — a teammate's laptop during pairing, a borrowed workstation, a fresh VM. A browser page with no signup fits perfectly: paste, format, close the tab, nothing to install and nothing to configure.
TidyCode covers the languages I touch most. For Python work I use https://tidycode.org/format/python, and the same page handles the JSON configs, SQL queries, YAML files, and XML feeds that show up in every real-world review. One bookmark, twenty-plus languages.
What about automated formatters in CI?
You might ask: why not just enforce formatting with a linter in CI? You should do that too — for your own repositories. But half the code I review isn't mine to configure: open-source contributions, code from contractors, snippets pasted into issues, legacy files I'm touching for the first time. For all of that, a manual ten-second pass is the pragmatic answer.
The real payoff
Formatting doesn't make you a better programmer. But it removes an entire category of noise from the one activity where attention is scarcest: reading someone else's code with the intent to judge it. It also makes you a kinder reviewer — it's much easier to be generous about someone's design choices when you're not fighting their whitespace.
Try it for a week. Format everything before you review it. I suspect your reviews will get faster, your comments will get more substantive, and the people whose code you review will quietly appreciate it.
Top comments (0)