gofmt and go vet — why Go code all looks the same

Most languages have ongoing style debates — tabs vs. spaces, where braces go, how long a line should be — usually settled per-project with a configurable linter. Go's official formatter, gofmt, ships with the language itself and is deliberately not configurable — there's no settings file, no team style guide to agree on, just one canonical way Go code is formatted.

The deliberate lack of configuration is the point, not a limitation: no project has to spend time deciding on a style, no code review ever debates formatting preferences, and — since the entire Go ecosystem uses the same formatter — code from a completely unrelated open-source project reads with the exact same layout as code on your own team. Nearly every Go editor integration runs gofmt automatically on save, so in practice, most Go developers never manually think about formatting at all.

gofmt only handles formatting — it has no opinion on whether the code is actually correct. go vet is a separate, also-built-in tool that examines code for common, real mistakes that compile fine but are almost certainly bugs:

This code compiles without error — Go's type system doesn't check format strings — but go vet recognizes the mismatch between %s and an int argument specifically, catching a real bug that would otherwise only show up as garbled output at runtime.

Running go fmt ./... and go vet ./... before committing (many teams wire both into a pre-commit hook or CI check automatically) catches an entire category of trivial-but-annoying review comments ("please format this") and a separate category of real, compiling-but-wrong bugs, both before a human reviewer ever has to spend time on either. This pairing — one tool for style, a separate one for correctness that style-checking alone can't catch — is a pattern worth recognizing in any language's tooling, not just Go's.