go-naming

# Go Naming Conventions Go uses naming to encode visibility (`UpperCamelCase` = exported, `lowerCamelCase` = unexported), so naming is load-bearing — not cosmetic. Names should be **short, contextual, and non-repetitive**. The package name is always present at the call site; pretending otherwise is the single biggest source of bad Go names. ## Core Rules 1. **MixedCaps only.** No underscores, no `SCREAMING_SNAKE_CASE`, no `kHungarian`. Exceptions: test subtests (`TestFoo_BadInput`), generated code, cgo. 2. **Capitalization is visibility.** `Exported`, `unexported`. Do not invent other conventions. 3. **No stuttering.** The package name is at the call site; `http.HTTPClient` is wrong, `http.Client` is right. 4. **Scope drives length.** `i` is fine in a 3-line loop; package-level vars need descriptive names. 5. **Initialisms keep one case.** `userID`, `HTTPServer`, `ParseURL` — never `userId`, `HttpServer`, `ParseUrl`. 6. **Receivers are 1-2 letter abbreviations**, consistent across all methods of the type. Never `this`/`self`. ## Naming Decision Flow ``` What are you naming? ├─ Package → lowercase single word, singular, specific (not util/common/helper) ├─ File → lowercase, underscores OK (user_handler.go) ├─ Interface → method + "-er" when single-method (Reader, Closer, Stringer) ├─ Struct/Type → MixedCaps noun (Request, FileHeader) ├─ Constructor → New() if package has one primary type; NewThing() if multiple ├─ Constant → MixedCaps; ne...