evilissimo/naming-things
Reviews and improves **names** in code — variables, functions, classes, modules, parameters — for clarity, intent, and consistency with language/team conventions. Triggers when asked to review names, rename things, improve code readability, clean up confusing code, or when examining code with generic/vague names like "data", "info", "manager", "temp", "util". Does NOT trigger for general code review unrelated to naming, architecture design, debugging, or performance optimization. Identifies naming anti-patterns (generic names, misleading names, type-encoding, abbreviations), suggests role-based names that reveal intent, checks consistency with project/domain vocabulary, and flags misalignment with language culture.
91
90%
Does it follow best practices?
Impact
94%
1.05xAverage score across 5 eval scenarios
Passed
No known issues
golang.mdreferences/
Go Naming Conventions
Based on Effective Go, the Go Code Review Comments, and community conventions.
Convention Table
| Thing | Convention | Example |
|---|---|---|
| Variable (local) | mixedCaps / camelCase | userName, totalCount |
| Exported variable | PascalCase | MaxRetryCount, DefaultTimeout |
| Function (unexported) | camelCase | calculateTotal(), getUser() |
| Function (exported) | PascalCase | ProcessOrder(), SendEmail() |
| Method receiver | 1-3 letter abbreviation | u *User, s *Store, r *Reader |
| Type (struct, interface) | PascalCase | CustomerOrder, HttpClient |
| Interface (1 method) | Name + er suffix | Reader, Writer, Stringer |
| Interface (multiple) | Descriptive | StorageBackend, PaymentGateway |
| Constant | mixedCaps / PascalCase | maxRetryCount, StatusOK |
| Package | short, lowercase, one word | http, json, fmt, strings |
| File | snake_case | order_service.go |
| Test function | PascalCase | TestProcessOrder |
| Benchmark | PascalCase | BenchmarkProcessOrder |
Key Points
- Brevity is expected — Go prefers shorter names than other languages, but clarity still wins
gofmtenforces style — but naming is convention, not automated- Receiver names should be short and consistent across methods on the same type (usually 1-3 chars)
- Single-letter receivers (
ufor*User,sfor*Store) are fine — don't useselforthis - Exported vs unexported = public vs private (capital letter = exported)
- Interface with one method gets the method name +
er:io.Reader,io.Writer,fmt.Stringer - Interface with multiple methods gets a descriptive name:
net.Listener,http.Handler - Avoid stutter — don't repeat package name:
http.Servernothttp.HttpServer,time.Durationnottime.TimeDuration - Boolean parameters often benefit from a wrapper function:
WithLogging()vsRun(true) - Package names are lowercase, concise, and importable:
json,xml,http(notjsonutils)
Stutter Examples
| Bad | Good | Reason |
|---|---|---|
order.OrderData | order.Order or order.Data | Type already in order package |
user.UserManager | user.Manager or user.Service | Package context makes it clear |
config.ConfigOptions | config.Options | Redundant prefix |
Common Offenses
| Bad | Good | Reason |
|---|---|---|
GetUser() | User() or FetchUser() | Get prefix is often unnecessary in Go |
this / self | u / s / c | Go convention is short receiver names |
util / common / misc | httphelper, stringutil | Better to organize by domain |
JsonParser | json.Parser or Parser | Stutter from package qualifier |
Data | orders, users, records | Too generic |
Init() | New() / Open() / Connect() | New is Go convention for constructors |