Go code has a long-running naming habit around initialisms: ID, URL, HTTP, API, and friends often stay fully capitalized inside identifiers. That gives you names like UserID, ParseURL, HTTPClient, and APIError.
I understand the convention, but I do not like how it reads.
My preference is simpler: treat abbreviations like normal words when they are part of a mixed-case identifier.
type ApiError struct{}
type HttpClient struct{}
func ParseUrl(userId string) {}
The reason is not that Api is more "correct" than API in isolation. It is that code is scanned in context. Once a codebase has a mix of ordinary words and all-caps abbreviation runs, identifiers start to look jagged. The reader has to remember which words are special, where the special casing starts, and where it stops.
I would rather remove the exception.
UserId follows the same visual rhythm as UserName. HttpClient follows the same rhythm as FileClient. ParseUrl follows the same rhythm as ParsePath. The names become less noisy because the rule is boring: use camel case everywhere.
That is why I made Camellia, a small golangci-lint module plugin for this exact preference.
Camellia flags project-declared Go identifiers with all-caps abbreviation runs and suggests the camel-case spelling instead:
type APIError struct{} // ApiError
type HTTPClient struct{} // HttpClient
func ParseURL(userID string) {} // ParseUrl, userId
It is intentionally narrow. It does not try to reformat your whole project or invent a broad style guide. It just enforces one naming choice consistently. Imported symbols are left alone, and if you need to roll the rule out gradually, Camellia supports its own exclude list for generated code, fixtures, or legacy paths.
If you also prefer ApiError over APIError, try it here: