Other Essential Go Tools

The go command is best known for building, running, and testing code. But the Go toolchain includes several other built‑in tools that you will reach for just as often once you start writing real projects. They do not compile code; they format it, inspect it for subtle bugs, generate source files from templates, and let you read documentation without leaving the terminal or your browser. Mastering them turns the Go toolchain from a compiler into a complete development environment.

Why These Tools Exist

Go was designed to make large‑scale development predictable. When hundreds of engineers work on the same codebase, differences in formatting, undiscovered mistakes, and out‑of‑date documentation cause real friction. Rather than relying on third‑party linters or formatters with conflicting settings, the Go team built the essential quality‑of‑life tools directly into the go command. They share the same design values as the language itself: convention over configuration, immediate feedback, and zero‑dependency operation.

These tools exist so that:

• Code looks the same regardless of who wrote it.
• Static checks catch errors before a test ever runs.
• Repetitive code generation has a standard, tool‑invokable mechanism.
• Package documentation is always one command away and can be served as a navigable website.

Using them consistently is not a bonus — it is how a Go project stays healthy.

The Tools at a Glance

Each tool in this section solves one specific problem and solves it well.

gofmt — Consistent Code Formatting

gofmt takes Go source and rewrites it into the standard Go style. It normalises indentation, whitespace, line breaks, and even alphabetises import groups. Because every developer uses the same formatting, code reviews stop being about brace placement and start being about logic. gofmt is also the foundation for Go’s automated refactoring support — you can pair it with rewrite rules to rename variables or replace outdated API calls across an entire module.

go vet — Suspicious Code Detection

go vet runs a suite of static analyzers that look for code that compiles but almost certainly does not do what the author intended. It catches mistakes like unreachable code, invalid struct tags, mismatched key/value pairs in composite literals, and calls to fmt.Printf where the format string does not match the arguments. Because go vet runs on the source without executing it, it catches an entire class of bugs before you ever hit go test.

go generate — Automated Code Generation

Some code is tedious to write by hand — mocks, stringer methods, embedded asset files, protocol buffer stubs. go generate is not a code generator itself. It is a driver that scans source files for specially formatted comments and runs the commands written in those comments. This standardises where and how code generation happens and ensures that generated files are always re‑producible from the same input. The tool itself stays simple; the generators are whatever program you invoke.

go doc — Terminal‑Based Documentation

go doc prints the documentation for a package, type, function, or method directly in the terminal. It works offline, respects Go’s documentation conventions, and is significantly faster than opening a browser and searching. During development, go doc is the fastest way to answer questions like “What does strings.ReplaceAll return?” or “What are the fields of http.Server?”

Godoc — Web‑Based Documentation Server

While go doc is for quick lookups, godoc is for browsing. It starts a local web server that renders package documentation as linked HTML pages — the same format you see on pkg.go.dev. Godoc also displays a package’s source code with cross‑referenced identifiers, making it a powerful tool for exploring unfamiliar libraries. It can run locally against your own code, giving you a full documentation site for a project that has never been published.

How These Tools Fit Into a Daily Workflow

A typical edit‑and‑test cycle in Go often looks like this:

1. Write or modify code.
2. Run gofmt (or set your editor to do it on save) so the code is canonical.
3. Run go vet to catch subtle mistakes immediately.
4. If the project uses code generation, run go generate to refresh generated files.
5. Use go doc to quickly check an API while staying in flow.
6. Build and test with go build / go test.

This pipeline catches formatting drift, logic bugs, and stale generated files long before a pull request reaches a reviewer. Tools like gofmt and go vet are also integrated into most Go editor plugins and CI systems, so you often get their feedback without running them manually. But understanding what each tool does and when to invoke it directly gives you full control.

Common Misconceptions

Developers new to Go sometimes misjudge what these tools are and are not.

“gofmt is just a style enforcer.” It is that, but it is also a refactoring tool. The -r flag allows pattern‑based code rewrites. This is not a find‑and‑replace; it understands Go syntax, so it can distinguish between a variable named foo and the string literal "foo".

“go vet is a linter.” It is better described as a collection of narrow, high‑confidence static checkers. Linters like golangci-lint cover a much broader range of stylistic and complexity rules. go vet only reports things that are very likely to be bugs, and it ships with the compiler. It is intentionally conservative.

“go generate runs automatically.” It never runs automatically — not during go build, go run, or go test. You must invoke it explicitly. This is by design, so that code generation does not introduce surprising side effects. If a generated file is missing and your code depends on it, the build will fail with a clear compiler error.

“go doc is only for the standard library.” It works for any package in your module, its dependencies, or installed packages. You can point it at local paths, too: go doc ./mypackage.

Choosing Between go doc and godoc

If you need a quick answer while coding, go doc is the right tool. It returns instantly and prints only the relevant section of documentation.

If you need to browse an unfamiliar package, see all exported identifiers, jump between types and methods, or read source code with syntax highlighting, godoc in a browser is a better experience. It also lets you serve documentation for multiple modules simultaneously, which is useful when you are working across several services that share internal libraries.