Package names

Canonical guidance

• Prefer short, lower-case package names.
• Let the import path provide context; do not repeat it in identifiers.
• Avoid generic names like util, common, or base unless the package really is that.
• Optimize for call-site readability.

Use when

• naming any new package
• reviewing public APIs
• splitting a large package into smaller ones

Avoid

• package utils
• stutter like http.HTTPServer
• cute abbreviations that are not standard to Go users

Preferred pattern

package httpapi

client := httpapi.NewClient()

Anti-pattern

package commonutils

client := commonutils.NewHTTPAPIClient()

Explanation: This anti-pattern is common because generic names feel reusable, but they make call sites vague and encourage dumping unrelated behavior together.

Why

• package names are read constantly at import sites and call sites
• shorter names reduce stutter and improve scan speed
• the best package names usually make extra explanation unnecessary