Go Naming Conventions: A Practical Guide
7 hours ago
- #Naming Conventions
- #Go
- #Best Practices
- Go has specific rules for naming identifiers: unicode letters, digits, underscores only; cannot start with a digit; cannot use Go keywords.
- Use camelCase for unexported identifiers and PascalCase for exported ones. Avoid snake_case, SCREAMING_SNAKE_CASE, etc.
- Acronyms or initialisms (like API, URL) should maintain consistent casing within the identifier (e.g., apiKey or APIKey, not ApiKey).
- Avoid non-ASCII letters in identifiers unless necessary (e.g., use 'pi' instead of 'π').
- Do not use identifiers that clash with Go's builtin types (e.g., int, bool) or functions (e.g., min, max).
- Generally, avoid including the type in identifiers (e.g., fullNameString is bad; fullName is better).
- Package names should be short, lowercase, and descriptive (e.g., 'orders' instead of 'OrderManager').
- Avoid 'catch-all' package names like 'utils' or 'helpers'—break them into smaller, focused packages.
- File names should summarize content, be lowercase, and avoid special prefixes/suffixes unless needed (e.g., _test.go for tests).
- Avoid repeating package names in exported functions (e.g., customer.New() instead of customer.NewCustomer()).
- Method receivers should be short (1-3 characters) and consistent across methods for the same type.
- Getter methods should not be prefixed with 'Get'; setters should use 'Set' (e.g., Name() and SetName()).
- Single-method interfaces should be named with '-er' suffix (e.g., Reader, Writer).
- Breaking conventions is rare but acceptable if it improves clarity (e.g., matching external system names).