A code review is more useful when reviewers do not have to catch every routine mistake. Static analysis checks source code without running the application, looking for known patterns associated with bugs, security vulnerabilities, or poor practices. It does not replace human review; it gives reviewers more time for work that needs judgment. section 5.4
Start with a fast check. In a Go repository, `go vet ./...` checks all packages and normally produces no output when it finds no issue. For example, adding an extra argument to a `fmt.Sprintf` call gives `go vet` a format mismatch to report before that change reaches testing. section 5.4
Make the checks part of the normal feedback path:
- Run formatting checks first, then `go vet`, then tests. Put the faster checks earlier so developers get specific feedback without waiting for later stages. section 5.4 section 5.8
- Use `golangci-lint` for additional checks. A `.golangci-lint.yml` configuration can enable `gosec` for security-related findings, while a CI lint job can run through the `golangci-lint` GitHub Action. section 5.4
- Extend the same mechanism to documentation quality: `stylecheck`, `godot`, and `misspell` can check exported-code comments, punctuation, and spelling. Run `make static-check`, fix the findings, and push the change. section 5.5
Listing 5.11 \golangci-lint.yml
linters:
enable:
- gosec
- godot #1
- misspell
- stylecheck
linters-settings: #2
stylecheck:
# Select the Go version to target. The default is '1.13'.
go: "1.18"
checks: ["all","ST1*"]
issues:
exclude-use-default: false #3
output:
format: colored-line-number
# print lines of code with issue, default is true
print-issued-lines: false
# print linter name in the end of issue text, default is true
print-linter-name: true
The linter configuration shows how security checks and comment-quality checks can share one repeatable static-analysis command. section 5.5 section 5.4
Treat a finding as actionable feedback, not as a substitute for testing or review. Keep the checks in the pipeline so known anti-patterns are caught before deployment, and adjust the process as the team learns where feedback is most useful. section 5.4 section 5.8
