golang-code-style

Linters like gofmt and gofumpt handle formatting, but judgment-based rules need explicit conventions. This skill covers early returns over nesting, named booleans for complex conditions, options structs for functions with more than 4 parameters, and value-versus-pointer argument decisions.

Use := for non-zero values and var for zero-value initialization, since the form signals intent. For example, use var count int when the counter starts at zero, but name := "default" when assigning a meaningful initial value.

Nil slices serialize to null in JSON while empty slices serialize to [], which surprises API consumers expecting an array. Nil maps additionally panic on write, so slices and maps should always be initialized with []T{} or make().

Pass small types like string, int, bool, and time.Time by value. Use pointers when the function mutates the argument, when the struct exceeds roughly 128 bytes, or when nil is meaningful for optional parameters.

No, it complements them. Linters enforce mechanical formatting automatically, while this skill handles clarity rules requiring judgment, such as reducing nesting and extracting complex conditions. It cross-references a separate golang-lint skill for automated enforcement.

It explicitly excludes naming conventions, linter configuration, and doc comments, which are handled by sibling skills golang-naming, golang-lint, and golang-documentation. Struct and interface design is covered by golang-structs-interfaces.