Lectures

Let’s break down why gofmt in Go is not “cosmetic”, but a standard for the team and the ecosystem: a deterministic style (same input → same output), clean diffs in Git, predictable {} braces, and tidy structs. We’ll show a mini “before/after” demo, the boundaries of what gofmt is responsible for, and how to run it manually via gofmt -w and -d.

We’ll break down why the import block in Go is part of the “contract” with the compiler, and how the goimports utility removes the routine: it formats a file like gofmt, automatically adds missing imports, removes unused ones, sorts and groups them. In practice, we’ll see how this works on the mini CLI “Tasker”, how aliases and _-imports are supported, and how to integrate goimports into your usual development cycle ( -w, -l) without “noise” in the diff.

We break down where go vet sits in the quality pipeline (after gofmt/ goimports and before go test), how to read its messages, and which warning classes you’ll see most often: printf (format strings), the string( int) trap, variable shadowing ( shadow), broken struct tags ( structtag), positional struct literals from other packages ( composites), and ignoring a result ( unusedresult).

We break down why Go needs linters in addition to the compiler and go vet, what staticcheck is good for, how the golangci-lint aggregator works, how not to drown in an “avalanche” of warnings, and how to start with a minimal .golangci.yml config. With examples, we will see typical findings (redundant checks, pointless assignments, error message style) and discuss intentional local suppression via //nolint.

We break down how to turn code quality into a repeatable contract via CI: what a quality gate is, why it matters to run the same commands locally and in the pipeline, how to set up the step order ( gofmt/ goimports → go vet → linters → go test), how to add a minimal workflow in GitHub Actions, how to “pin” tool versions via go install ...@version, and how to quickly read pipeline failures using the fail fast principle.