Code Formatter
A tool that rewrites source code into one canonical layout automatically, ending style debates in code review and keeping diffs focused on what changed.
A code formatter rewrites source code into a single consistent layout: indentation, line breaks, spacing, quotes, trailing commas. You run it, or more often your editor or a Git Hook runs it on save or commit, and the file comes out the same way no matter who wrote it.
Formatters work on structure rather than text. Most parse the code into an Abstract Syntax Tree, throw away the original whitespace, and print the tree back out by their own rules, wrapping lines to fit a width limit. Because the output depends only on the program's structure, formatting the same code twice gives the same result, and the tool should never change what the program does.
The modern wave began with gofmt, which shipped with Go in 2009 and offered almost no options. The Go proverb summarizes the effect: "gofmt's style is no one's favorite, yet gofmt is everyone's favorite." Prettier brought the same idea to JavaScript in 2017, and Black for Python ("the uncompromising code formatter") and rustfmt for Rust took the same approach. The common design choice is to minimize configuration. Every option is a decision a team must argue about, so removing options is the feature.
What formatters buy is mostly social:
- No style debates in review. Comments about brace placement are pure bikeshedding, the easiest thing in a diff to have an opinion on. With a formatter there is nothing to discuss, and Code Review attention goes to logic.
- Clean diffs. When everyone's editor formats identically, a change touches only lines whose meaning changed, rather than reflowing whitespace. That keeps merge conflicts rarer and history readable.
- Lower friction moving between codebases. Code in a well-formatted ecosystem looks familiar everywhere.
Formatters are distinct from linters. A formatter fixes layout and never changes behavior; a linter, a kind of Static Analysis, flags suspicious code, some of which it can fix. Many teams run both, the formatter first.
Adopting a formatter on an existing codebase has one known cost: a single huge commit that touches nearly every line, which pollutes line-by-line history. Git can skip it: listing the commit in a .git-blame-ignore-revs file tells Git Blame to look past it to the real author of each line. Teams often land the reformat during a quiet period to avoid conflicts with open branches.
Enforcement usually happens twice: locally, so developers rarely see a failure, and in Continuous Integration, which runs the formatter in check mode and fails if any file would change. That makes the formatted layout a property of the repository, not a habit of its contributors.
See also3
Developer Experience
How it feels to build software with a given set of tools, codebase, and process, shaped mostly by how fast feedback arrives, how much a developer must hold in mind, and how often they can work uninterrupted.
Version Control & Delivery7 connections
Line Ending
The invisible characters marking where a line of text ends, split three ways since the teletype era between Unix, Windows, and classic Mac OS, and still breaking scripts and diffs.
Systems & Tooling9 connections
Lexical Analysis
The first stage of reading a program, which groups a stream of characters into tokens such as names, numbers, operators and keywords, usually using regular expressions compiled into a finite automaton, so the parser can work with words rather than letters.
Computation & Algorithms9 connections
Linked from9
- Conventional CommitsVersion Control & Delivery
A lightweight convention giving commit messages a machine-readable type and scope.
- Developer ExperienceVersion Control & Delivery
How it feels to build software with a given set of tools, codebase, and process, shaped mostly by how fast feedback arrives, how much a developer must hold in mind, and how often they can work uninterrupted.
- DiffVersion Control & Delivery
The listing of changes between two versions of a file, the algorithms that compute it, and the unified format that code review, patches, and merges are built on.
- Git BlameVersion Control & Delivery
Showing, for every line of a file, the commit and author that last changed it, the starting point for finding out why code is the way it is.
- Law of TrivialityMethod
The time spent debating an item is inversely proportional to its actual stakes.
- Lexical AnalysisComputation & Algorithms
The first stage of reading a program, which groups a stream of characters into tokens such as names, numbers, operators and keywords, usually using regular expressions compiled into a finite automaton, so the parser can work with words rather than letters.
- Line EndingSystems & Tooling
The invisible characters marking where a line of text ends, split three ways since the teletype era between Unix, Windows, and classic Mac OS, and still breaking scripts and diffs.
- RefactoringMethod
Changing the structure of code without changing what it does, in small verified steps, so that the next change becomes easy.
- Staging AreaVersion Control & Delivery
The intermediate snapshot in Git between the working files and the next commit, which lets a developer choose exactly which changes go into each commit, down to individual lines.