A code formatter is a tool that takes source code and rewrites its layout, indentation, line breaks, spacing, and bracket placement, into a single consistent style, usually leaving the program’s behavior untouched. Unlike a linter, which mostly reports problems for a human to fix, a formatter changes the file directly. The point is not to find one correct way to format code in the abstract, but to remove formatting as a thing anyone has to decide or argue about.
The idea reached its sharpest expression with Go. The Go team shipped gofmt, invoked as “go fmt”, and made a single canonical format part of the language’s culture. The official Go blog post from January 23, 2013 argues that gofmt’d code is “easier to write,” “easier to read,” and “easier to maintain,” and bluntly promises that with it you will “never have a debate about spacing or brace position ever again.” A crucial side benefit is mechanical refactoring: because formatting is deterministic, “mechanical changes to the source don’t cause unrelated changes to the file’s formatting; diffs show only the real changes.” Go deliberately offers no configuration, there is one true style, and that absence of options is the feature.
Prettier brought the same philosophy to the messier world of JavaScript and the web. Its own documentation frames the goal as ending arguments: Prettier exists to “stop all the on-going debates over styles” by being a style guide that is fully automatic. The pitch is that by accepting an opinionated, mostly non-configurable tool, a team trades away personal preferences in exchange for never spending review cycles on layout again, and for onboarding newcomers who no longer need to learn unwritten formatting conventions. Python’s Black markets itself the same way, as “the uncompromising code formatter.”
What unites gofmt, Black, and Prettier is the decision to remove choice on purpose. Earlier “pretty printers” and editor reformatters tended to expose dozens of knobs, which simply moved the style argument from “how should we indent” to “how should we configure the indenter.” The modern formatter answers that by being opinionated: it picks the rules so the team does not have to. The trade is real but deliberate, and for many projects the gain in consistency and the elimination of style debates is worth giving up control over the details.
Formatters now sit in the same automated pipeline as linters. They run on save in editors, as pre-commit hooks, and in continuous integration, where a build can fail if code is not already formatted. Combined with a shared editor configuration like .editorconfig and a linter for correctness, an automatic formatter lets a team guarantee that every file in the repository looks the same regardless of who wrote it or which editor they used.