Code Formatter for Legacy Projects How to Enforce a Consistent Style Guide Without Rewriting Your Entire Codebase

You inherit a codebase. It is 500 files of JavaScript, CSS, and JSON — written by 8 different developers over 5 years. Some files use 2-space indentation. Some use 4-space. Some use tabs. Three files mix tabs and spaces within the same function. The style guide was "whatever your IDE defaults to." There was no enforcement. The codebase is functional. It is also unreadable. New developers spend their first week learning not the code, but which files use which formatting style.

You propose: "Let's format the entire codebase with a code formatter." The team objects: "That will create 500 files of formatting-only changes. We will lose git blame. We will never be able to merge our existing branches." The objection is valid. The solution is not to format everything at once. It is to format incrementally. Here is the slow migration strategy.

Why "Format Everything at Once" Fails

Formatting the entire codebase in one commit has real costs: git blame becomes useless (every line in every file now has the same commit — the format commit), active branches become unmergeable (every open pull request now conflicts with the format commit), and the diff is unreadable (500 files changed with formatting-only changes — no human can review it). The format-everything approach is fast. It is also destructive. The damage to the git history and the team's workflow outweighs the benefit of consistent formatting.

The Incremental Migration Strategy

Rule 1: Format only the files you touch. When a developer opens a file to fix a bug or add a feature, they format that file first — in a separate commit: "Format: utils.js." Then they make their changes in a second commit. The format commit and the change commit are separate. The git blame for the format commit points to "formatting." The git blame for the change commit points to the actual code change. The history is preserved.

Rule 2: Use the online formatter for one-off files. When a developer needs to format a single file, they paste it into the code formatter, copy the output, and commit. No build tool configuration. No npm install. No dependency conflicts. The online formatter handles the file. The developer handles the commit. The workflow is: open file → paste into formatter → copy output → commit → make changes → commit.

Rule 3: Track progress. Count how many files have been formatted vs total files. 100/500 = 20% formatted. The metric shows progress. The metric motivates. Without the metric, formatting is an invisible goal that never feels closer. With the metric, every formatted file moves the number.

When to Format Everything at Once (the Exception)

Format everything at once when: the codebase is small (under 50 files), there are no active branches, and the team agrees. In all other cases, the incremental strategy preserves git history, avoids merge conflicts, and actually gets adopted. Use the code formatter for one file at a time. Format the files you touch. Watch the percentage climb. One file at a time, the codebase becomes consistent.