Go Safety: Correctness & Defensive Coding

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

1. Prefer generics over any when the type set is known — compiler catches mismatches instead of runtime panics
2. 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).
3. Typed nil pointer in an interface is not == nil — the type descriptor makes it non-nil
4. Writing to a nil map panics — always initialize before use
5. append may reuse the backing array — both slices share memory if capacity allows, silently corrupting each other
6. Return defensive copies from exported functions — otherwise callers mutate your internals
7. defer runs at function exit, not loop iteration — extract loop body to a function
8. Integer conversions truncate silently — int64 to int32 wraps without error
9. Float arithmetic is not exact — use epsilon comparison or math/big
10. Design useful zero values — nil map fields panic on first write; use lazy init
11. Use sync.Once for 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:

// ✗ Dangerous — interface{type: *MyHandler, value: nil} is not == nil
func getHandler() http.Handler {
    var h *MyHandler // nil pointer
    if !enabled {
        return h // interface{type: *MyHandler, value: nil} != nil
    }
    return h
}

// ✓ Good — return nil explicitly
func getHandler() http.Handler {