Golang Safety
Defensive Golang coding against accidental bugs, nil panics, typed-nil interfaces...
Install
npx skills add samber/cc-skills-golang --skill golang-safety -g -a claude-code -y- Repository
- samber/cc-skills-golang3.8k
- Category
- Design
- Updated
- 3d ago
- License
- MIT
- Context cost
- Mediumabout 2,328 tokens
- Runs scripts
- No, instructions only
What it does
Defensive Golang coding against accidental bugs, nil panics, typed-nil interfaces, `append` backing-array aliasing, silent int64-to-int32 truncation, float `==` comparison, `defer` inside loops, defensive copies of slices and maps, and usable zero values. Use when a Go program panics on a nil map write or nil pointer dereference, when reviewing code for nil-safety, numeric conversion overflow, or resource lifecycle, or when designing a type whose zero value must be safe. Not for designing concurrent access with goroutines, channels, or sync primitives (→ See `samber/cc-skills-golang@golang-concurrency` skill), not for exploitable vulnerabilities such as injection, weak crypto, or leaked secrets (→ See `samber/cc-skills-golang@golang-security` skill), and not for debugging an already-failing program (→ See `samber/cc-skills-golang@golang-troubleshooting` skill).
Persona: You are a defensive Go engineer. You treat every untested assumption about nil, capacity, and numeric range as a latent crash waiting to happen.
Go Safety: Correctness & Defensive Coding
Prevents programmer mistakes, bugs, panics, and silent data corruption in normal (non-adversarial) code. Security handles attackers; safety handles ourselves.
Best Practices Summary
- Prefer generics over
anywhen the type set is known, compiler catches mismatches instead of runtime panics - Always use safe type assertions, for normal interfaces use comma-ok (
v, ok := x.(T)); for reflection in Go 1.25+ preferreflect.TypeAssert[T](value)overvalue.Interface().(T). - Typed nil pointer in an interface is not
== nil, the type descriptor makes it non-nil - Writing to a nil map panics, always initialize before use
appendmay reuse the backing array, both slices share memory if capacity allows, silently corrupting each other- Return defensive copies from exported functions, otherwise callers mutate your internals
deferruns at function exit, not loop iteration, extract loop body to a function- Integer conversions truncate silently,
int64toint32wraps without error - Float arithmetic is not exact, use epsilon comparison or
math/big - Design useful zero values, nil map fields panic on first write; use lazy init
- Use
sync.Oncefor lazy init, guarantees exactly-once even under concurrency
Nil Safety
Nil-related panics are the most common crash in Go.
The nil interface trap
Interfaces store (type, value). An interface is nil only when both are nil. Returning a typed nil pointer sets the type descriptor, making it non-nil:
