Defensive Golang coding to prevent panics, silent data corruption, and subtle runtime bugs. Use when encountering nil panics, append aliasing, map concurrent…
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 any when 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+ prefer reflect.TypeAssert[T](value) over value.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 append may 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 defer runs at function exit, not loop iteration — extract loop body to a function Integer conversions truncate silently — int64 to int32 wraps 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.Once for lazy init — guarantees exactly-once even under concurrency
don't have the plugin yet? install it then click "run inline in claude" again.