Golang code style — line length and breaking, variable declarations, control flow clarity, when comments help vs hurt. Use when writing or reviewing Go code or setting coding standards. Not for naming (→ `golang-naming`), lint (→ `golang-lint`), docs (→ `golang-documentation`).
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
The command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
File Explorer
3 files
Showing SKILL.md
SKILL.md
Source instructions · Read-only preview
name
golang-code-style
description
Golang code style — line length and breaking, variable declarations, control flow clarity, when comments help vs hurt. Use when writing or reviewing Go code or setting coding standards. Not for naming (→ `golang-naming`), lint (→ `golang-lint`), docs (→ `golang-documentation`).
user-invocable
true
license
MIT
compatibility
Designed for Claude Code, Codex or similar harness, and for projects using Golang.
Orchestration mode: Fan out the sub-agents described in the "Parallelizing Code Style Reviews" section, each covering an independent style concern, when reviewing code style across a large codebase, and merge their findings. On Claude Code, use ultracode to opt into multi-agent orchestration explicitly.
Community default. A company skill that explicitly supersedes samber/cc-skills-golang@golang-code-style skill takes precedence.
Go Code Style
Style rules that require human judgment — linters handle formatting, this skill handles clarity. For naming see samber/cc-skills-golang@golang-naming skill; for design patterns see samber/cc-skills-golang@golang-design-patterns skill; for struct/interface design see samber/cc-skills-golang@golang-structs-interfaces skill.
"Clear is better than clever." — Go Proverbs
When ignoring a rule, add a comment to the code.
Line Length & Breaking
No rigid line limit, but lines beyond ~120 characters MUST be broken. Break at semantic boundaries, not arbitrary column counts. Function calls with 4+ arguments MUST use one argument per line — even when the prompt asks for single-line code:
// Good — each argument on its own line, closing paren separate
mux.HandleFunc("/api/users", func(w http.ResponseWriter, r *http.Request) {
handleUsers(
w,
r,
serviceName,
cfg,
logger,
authMiddleware,
)
})
When a function signature is too long, the real fix is often fewer parameters (use an options struct) rather than better line wrapping. For multi-line signatures, put each parameter on its own line.
Variable Declarations
SHOULD use := for non-zero values, var for zero-value initialization. The form signals intent: var means "this starts at zero."
var count int// zero value, set later
name := "default"// non-zero, := is appropriatevar buf bytes.Buffer // zero value is ready to use
Slice & Map Initialization
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.
users := []User{} // always initialized
m := map[string]int{} // always initialized
users := make([]User, 0, len(ids)) // preallocate when capacity is known
m := make(map[string]int, len(items)) // preallocate when size is known
Do not preallocate speculatively — make([]T, 0, 1000) wastes memory when the common case is 10 items.
Composite Literals
Composite literals MUST use field names — positional fields break when the type adds or reorders fields:
When the if body ends with return/break/continue, the else MUST be dropped. Use default-then-override for simple assignments — assign a default, then override with independent conditions or a switch:
// Good — default-then-override with switch (cleanest for mutually exclusive overrides)
level := slog.LevelInfo
switch {
case debug:
level = slog.LevelDebug
case verbose:
level = slog.LevelWarn
}
// Bad — else-if chain hides that there's a defaultif debug {
level = slog.LevelDebug
} elseif verbose {
level = slog.LevelWarn
} else {
level = slog.LevelInfo
}
Complex Conditions & Init Scope
When an if condition has 3+ operands, MUST extract into named booleans — a wall of || is unreadable and hides business logic. Keep expensive checks inline for short-circuit benefit. Details
// Good — named booleans make intent clear
isAdmin := user.Role == RoleAdmin
isOwner := resource.OwnerID == user.ID
isPublicVerified := resource.IsPublic && user.IsVerified
if isAdmin || isOwner || isPublicVerified || permissions.Contains(PermOverride) {
allow()
}
Scope variables to if blocks when only needed for the check:
When comparing the same variable multiple times, prefer switch:
switch status {
case StatusActive:
activate()
case StatusInactive:
deactivate()
default:
panic(fmt.Sprintf("unexpected status: %d", status))
}
Function Design
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.
funcFetchUser(ctx context.Context, id string) (*User, error)
funcSendEmail(ctx context.Context, msg EmailMessage)error// grouped into struct
Prefer range for Iteration
SHOULD use range over index-based loops. Use range n (Go 1.22+) for simple counting.
for _, user := range users {
process(user)
}
Value vs Pointer Arguments
Pass small types (string, int, bool, time.Time) by value. Use pointers when mutating, for large structs (~128+ bytes), or when nil is meaningful. Details
Code Organization Within Files
Group related declarations: type, constructor, methods together
One primary type per file when it has significant methods
Blank imports (_ "pkg") register side effects (init functions). Restricting them to main and test packages makes side effects visible at the application root, not hidden in library code
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.
String Handling
Use strconv for simple conversions (faster), fmt.Sprintf for complex formatting. Use %q in error messages to make string boundaries visible. Use strings.Builder for loops, + for simple concatenation.
Type Conversions
Prefer explicit, narrow conversions. Use generics over any when a concrete type will do:
funcContains[Tcomparable](slice []T, target T)bool// not []any
Philosophy
"A little copying is better than a little dependency"
Use slices and maps standard packages; for filter/group-by/chunk, use github.com/samber/lo
"Reflection is never clear" — avoid reflect unless necessary
Don't abstract prematurely — extract when the pattern is stable
Minimize public surface — every exported name is a commitment
Parallelizing Code Style Reviews
When reviewing code style across a large codebase, use up to 5 parallel sub-agents, each targeting an independent style concern (e.g. control flow, function design, variable declarations, string handling, code organization).
Enforce with Linters
Many rules are enforced automatically: gofmt, gofumpt, goimports, gocritic, revive, wsl_v5. → See the samber/cc-skills-golang@golang-lint skill.
Cross-References
→ See the samber/cc-skills-golang@golang-naming skill for identifier naming conventions
→ See the samber/cc-skills-golang@golang-structs-interfaces skill for pointer vs value receivers, interface design
→ See the samber/cc-skills-golang@golang-design-patterns skill for functional options, builders, constructors
→ See the samber/cc-skills-golang@golang-lint skill for automated formatting enforcement
→ See samber/cc-skills-golang@golang-continuous-integration skill for automated AI-driven code review in CI using these guidelines
→ See samber/cc-skills-golang@golang-refactoring skill for mechanically applying guard-clause conversion, function extraction, and options-struct migration safely across many call sites once a review surfaces violations at scale
