“Style” rules can change program semantics and public APIs
Source references: 3The Skill goes beyond formatting: it requires collections never to be nil, recommends options structs above four parameters, and calls for aggressive unexporting. Nil and empty collections can carry different contract meanings, while signatures and export status define what callers can use.
Applying these rules to an existing project could change JSON output, break logic that relies on nil, or make downstream code fail to compile. Unexporting can also be a breaking API change.
These are not purely formatting rules. If mechanically applied to existing code, “never nil” collections can change JSON or caller-visible nil/empty semantics; an options struct changes function signatures; unexporting names can break external callers. The risk arises when these rules are used to modify an existing API. A user can require report-only review and prohibit collection-semantic, exported-name, or signature changes without itemized approval.
Slices and maps MUST be initialized explicitly, never nil. Nil maps panic on write; nil slices serialize to `null` in JSON (vs `[]` for empty slices), surprising API consumers.Show 2 other places
- Functions SHOULD be **short and focused** — one function, one job.- Functions SHOULD have **≤4 parameters**. Beyond that, use an options struct (see `samber/cc-skills-golang@golang-design-patterns` skill).- **Parameter order**: `context.Context` first, then inputs, then output destinations.- Naked returns help in very short functions (1-3 lines) where return values are obvious, but become confusing when readers must scroll to find what's returned — name returns explicitly in longer functions.- **Dot imports** pollute the namespace and make it impossible to tell where a name comes from — never use in library code- **Unexport aggressively** — you can always export later; unexporting is a breaking change. → See `samber/cc-skills-golang@golang-gopls` skill to unexport safely — its rename updates every call site atomically and refuses the change when lowercasing a method would break interface satisfaction, a breakage grep/sed silently ships.