go / checks

updated May 03, 2026

I run four checks before committing Go code:

goimports -local "$(go list -m)" -w .
go vet ./...
go test ./...
deadcode -test ./...

Order

The checks run fast-to-slow to fail fast:

1. goimports: Formats code and fixes imports. Runs first so other tools see properly formatted code.
2. go vet: Static analysis. Catches bugs before spending time on tests.
3. go test: Runs tests. No point running if vet already found issues.
4. deadcode: Finds unreachable functions. Slowest (whole-program analysis), informational.

goimports

goimports formats code like gofmt and also adds/removes imports.

go install golang.org/x/tools/cmd/goimports@latest

I install this via my laptop script.

The -local flag groups imports into three sections: standard library, third-party, and local module.

import (
    "fmt"
    "net/http"

    "github.com/someone/pkg"

    "mymodule/internal/foo"
)

go vet

go vet reports likely mistakes: printf format errors, unreachable code, suspicious constructs.

It's built into Go and runs fast.

go test

go test runs tests.

The ./... pattern matches all packages in the module.

deadcode

deadcode finds functions that are never called.

go install golang.org/x/tools/cmd/deadcode@latest

I install this via my laptop script.

It uses whole-program analysis starting from main, so it only works on executables, not libraries.

The -test flag includes test binaries in the analysis:

deadcode -test ./...

This creates a virtuous cycle for codebase quality. When deadcode reports an unreachable function, you have two options:

1. Remove it. The function is genuinely unused.
2. Add a test. The function is used but not covered by tests.

Either outcome improves the codebase: less dead code or better test coverage.

The -test flag is especially useful for projects with multiple entry points (WASM, CLI tools, etc.) where some functions are only reachable from entry points that deadcode can't analyze natively.

How they run

The same commands live in two places, so I rarely run them by hand:

• AI agents read the project's AGENTS.md files (root and per-subdirectory), which list the checks with conditional rules: "run X if Y files touched." See ai/agents for the patterns I use.
• CI runs them via cibot. Each line of cibot's Testfile is a named check. Output is plain text, so a failed run pastes cleanly back into an agent prompt.

Security: govulncheck

govulncheck uses the Go Vulnerability Database and static analysis to filter out vulnerabilities that don't affect your code. Dependabot can't do this, so it opens noisy PRs for vulnerabilities in packages you don't even call. See Filippo Valsorda's Turn Dependabot Off.

Run periodically:

go run golang.org/x/vuln/cmd/govulncheck@latest ./...

Test against latest dependencies

Test against the newest dependency versions to catch breakage early:

go get -u -t ./...
go mod tidy
go test ./...
git checkout go.mod go.sum  # restore pinned versions

← All articles