golang-safety

1**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.
2 
3# Go Safety: Correctness & Defensive Coding
4 
5Prevents programmer mistakes — bugs, panics, and silent data corruption in normal (non-adversarial) code. Security handles attackers; safety handles ourselves.
6 
7## Best Practices Summary
8 
91. **Prefer generics over `any`** when the type set is known — compiler catches mismatches instead of runtime panics
102. **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)`.
113. **Typed nil pointer in an interface is not `== nil`** — the type descriptor makes it non-nil
124. **Writing to a nil map panics** — always initialize before use
135. **`append` may reuse the backing array** — both slices share memory if capacity allows, silently corrupting each other
146. **Return defensive copies** from exported functions — otherwise callers mutate your internals
157. **`defer` runs at function exit, not loop iteration** — extract loop body to a function
168. **Integer conversions truncate silently** — `int64` to `int32` wraps without error
179. **Float arithmetic is not exact** — use epsilon comparison or `math/big`
1810. **Design useful zero values** — nil map fields panic on first write; use lazy init
19…