Go Naming

Go Naming Conventions

Available Scripts

• `scripts/check-naming.sh` — Scans Go code for naming anti-patterns: SCREAMING_SNAKE_CASE constants, Get-prefixed getters, bad package names (util/helper/common), and receivers named "this"/"self". Run bash scripts/check-naming.sh --help for options.

Core Principle

Names should:

• Not feel repetitive when used
• Take context into consideration
• Not repeat concepts that are already clear

Naming is more art than science—Go names tend to be shorter than in other languages.

---

Naming Decision Flow

What are you naming?
├─ Package       → Short, lowercase, singular noun (no underscores, no mixedCaps)
├─ Interface     → Method name + "-er" suffix when single-method (Reader, Writer)
├─ Receiver      → 1-2 letter abbreviation of type (c for Client); consistent across methods
├─ Constant      → MixedCaps; use iota for enums; no ALL_CAPS
├─ Exported func → Verb or verb-phrase in MixedCaps; no Get prefix for getters
├─ Variable      → Length proportional to scope distance
│                  ├─ Tiny scope (1-7 lines) → single letter (i, n, r)
│                  ├─ Medium scope           → short word (count, buf)
│                  └─ Package-level / wide   → descriptive (userAccountCount)
└─ Any name      → Check: does it repeat package name or context? If yes, shorten it

---

MixedCaps (Required)

Normative: All Go identifiers must use MixedCaps.

Underscores are allowed only in: test functions (TestFoo_InvalidInput), generated code, and OS/cgo interop.

---

Package Names

Normative: Packages must be lowercase with no underscores.

Short, lowercase, singular nouns. Avoid generic names like util, common, helper — prefer specific names: stringutil, httpauth, configloader.

// Good: user, oauth2, tabwriter
// Bad:  user_service, UserService, count (shadows var)

Read references/IDENTIFIERS.md when naming packages, deciding on import aliases, or choosing between generic and specific package names.

---

Interface Names

Advisory: One-method interfaces use "-er" suffix.

Name one-method interfaces by the method plus -er: Reader, Writer, Formatter. Honor canonical method names (Read, Write, Close, String) and their signatures.

Read references/IDENTIFIERS.md when defining new interfaces or implementing well-known method signatures.

---

Receiver Names

Normative: Receivers must be short abbreviations, used consistently.

One or two letters abbreviating the type, consistent across all methods: func (c *Client) Connect(), func (c *Client) Send(). Never use this or self.

Read references/IDENTIFIERS.md when choosing receiver names or ensuring consistency across methods.

---

Constant Names

Normative: Constants use MixedCaps, never ALL_CAPS or K prefix.

Name constants by role, not value: MaxRetries not Three, DefaultPort not Port8080.

const MaxPacketSize = 512
const defaultTimeout = 30 * time.Second

Read references/IDENTIFIERS.md when naming constants or choosing between role-based and value-based names.

---

Initialisms and Acronyms

Normative: Initialisms maintain consistent case throughout.

Initialisms (URL, ID, HTTP, API) must be all uppercase or all lowercase: HTTPClient, userID, ParseURL() — not HttpClient, orderId, ParseUrl().

Read references/IDENTIFIERS.md when using initialisms in compound names or for the full case table.

---

Function and Method Names

Advisory: No Get prefix for simple accessors; use verb-like names for actions.

Getter for field owner is Owner(), not GetOwner(). Setter is SetOwner(). Use Compute or Fetch for expensive operations.

When functions differ only by type, include type at the end: ParseInt(), ParseInt64().

Read references/IDENTIFIERS.md when designing getter/setter APIs or naming function variants.

---

Variable Names

Variable naming balances brevity with clarity. Key principles:

• Scope-based length: Short names (i, v) for small scopes; longer,

descriptive names for larger scopes

• Single-letter conventions: Use familiar patterns (i for index,

r/w for reader/writer)

• Avoid type in name: Use users not userSlice, name not nameString
• Prefix unexported globals: Use _ prefix for package-level unexported

vars/consts to prevent shadowing

for i, v := range items { ... }           // small scope
pendingOrders := filterPending(orders)    // larger scope
const _defaultPort = 8080                 // unexported global

Read references/VARIABLES.md when naming local variables in functions over 15 lines.

---

Avoiding Repetition

Go names should not feel repetitive when used. Consider the full context:

• Package + symbol: widget.New() not widget.NewWidget()
• Receiver + method: p.Name() not p.ProjectName()
• Context + type: In package sqldb, use Connection not DBConnection

Read references/REPETITION.md when a package name and its exported symbols feel redundant.

---

Avoid Built-In Names

Never shadow Go's predeclared identifiers (error, string, len, cap, append, copy, new, make, etc.) as variable, parameter, or type names.

For detailed guidance: See go-declarations — "Avoid Using Built-In Names" section.

---

Quick Reference

Validation: After renaming identifiers, run bash scripts/check-naming.sh to verify no naming anti-patterns remain. Then run go build ./... to confirm the rename didn't break anything.

Related Skills

• Interface naming: See go-interfaces when naming interfaces with the -er suffix or choosing receiver types
• Package naming: See go-packages when naming packages, avoiding util/common, or resolving import collisions
• Error naming: See go-error-handling when naming sentinel errors (ErrFoo) or custom error types
• Declaration scope: See go-declarations when variable name length depends on scope or when avoiding built-in shadowing
• Style principles: See go-style-core when balancing clarity vs concision in identifier names

Identifier Naming Rules

Detailed rules and examples for naming Go packages, interfaces, receivers, constants, initialisms, and functions.

Package Names

Normative: Packages must be lowercase with no underscores.

Package names must be:

• Concise and lowercase only
• No underscores (e.g., tabwriter not tab_writer)
• Not likely to shadow common variables

// Good: user, oauth2, k8s, tabwriter
// Bad: user_service (underscores), UserService (uppercase), count (shadows var)

Avoid Uninformative Names

Advisory: Don't use generic package names.

Avoid names that tempt users to rename on import: util, common, helper, model, base. Prefer specific names: stringutil, httpauth, configloader.

Import Renaming

When renaming imports, the local name must follow package naming rules: import foopb "path/to/foo_go_proto" (not foo_pb with underscore).

---

Interface Names

Advisory: One-method interfaces use "-er" suffix.

By convention, one-method interfaces are named by the method name plus an -er suffix to construct an agent noun:

// Standard library examples
type Reader interface { Read(p []byte) (n int, err error) }
type Writer interface { Write(p []byte) (n int, err error) }
type Formatter interface { Format(f State, verb rune) }
type CloseNotifier interface { CloseNotify() <-chan bool }

Honor canonical method names (Read, Write, Close, String) and their signatures. If your type implements a method with the same meaning as a well-known type, use the same name—call it String not ToString.

---

Receiver Names

Normative: Receivers must be short abbreviations, used consistently.

Receiver variable names must be:

• Short (one or two letters)
• Abbreviations for the type itself
• Consistent across all methods of that type

// Good - consistent short receiver
func (c *Client) Connect() error
func (c *Client) Send(msg []byte) error
func (c *Client) Close() error

// Bad - inconsistent or long receivers
func (client *Client) Connect() error
func (cl *Client) Send(msg []byte) error
func (this *Client) Close() error

---

Constant Names

Normative: Constants use MixedCaps, never ALL_CAPS or K prefix.

// Good
const MaxPacketSize = 512
const defaultTimeout = 30 * time.Second

// Bad
const MAX_PACKET_SIZE = 512    // no snake_case
const kMaxBufferSize = 1024    // no K prefix

Name by Role, Not Value

Advisory: Constants should explain what the value denotes.

// Good - names explain the role
const MaxRetries = 3
const DefaultPort = 8080

// Bad - names just describe the value
const Three = 3
const Port8080 = 8080

---

Initialisms and Acronyms

Normative: Initialisms maintain consistent case throughout.

Initialisms (URL, ID, HTTP, API) should be all uppercase or all lowercase:

// Good: HTTPClient, userID, ParseURL()
// Bad: HttpClient, orderId, ParseUrl()

---

Function and Method Names

Getters and Setters

Advisory: Don't use Get prefix for simple accessors.

If you have a field called owner (unexported), the getter should be Owner() (exported), not GetOwner(). The setter, if needed, is SetOwner():

// Good
owner := obj.Owner()
if owner != user {
    obj.SetOwner(user)
}

// Bad: c.GetName(), u.GetEmail(), p.GetID()

Use Compute or Fetch for expensive operations: db.FetchUser(id), stats.ComputeAverage().

Naming Conventions

Advisory: Use noun-like names for getters, verb-like names for actions.

// Noun-like for returning values
func (c *Config) JobName(key string) string
func (u *User) Permissions() []Permission

// Verb-like for actions
func (c *Config) WriteDetail(w io.Writer) error

Type Suffixes

When functions differ only by type, include type at the end: ParseInt(), ParseInt64(), AppendInt(), AppendInt64().

For a clear "primary" version, omit the type: Marshal() (primary), MarshalText() (variant).

Avoiding Repetition

This reference covers how to avoid redundant naming in Go by considering the context where names appear—package, receiver type, and surrounding code.

Package vs. Exported Symbol

Advisory: Don't repeat package name in exported symbols.

// Bad - repetitive at call site
package widget
func NewWidget() *Widget           // widget.NewWidget()
func NewWidgetWithName(n string)   // widget.NewWidgetWithName()

// Good - concise at call site
package widget
func New() *Widget                 // widget.New()
func NewWithName(n string) *Widget // widget.NewWithName()

// Bad
package db
func LoadFromDatabase() error      // db.LoadFromDatabase()

// Good
package db
func Load() error                  // db.Load()

Method vs. Receiver Type

Advisory: Don't repeat receiver type in method name.

// Bad
func (c *Config) WriteConfigTo(w io.Writer) error
func (p *Project) ProjectName() string

// Good
func (c *Config) WriteTo(w io.Writer) error
func (p *Project) Name() string

Context vs. Local Names

Advisory: Omit information already clear from context.

// Bad - in package "ads/targeting/revenue/reporting"
type AdsTargetingRevenueReport struct{}

// Good
type Report struct{}

// Bad - in package "sqldb"
type DBConnection struct{}

// Good
type Connection struct{}

Complete Example

// Bad - excessive repetition
func (db *DB) UserCount() (userCount int, err error) {
    var userCountInt64 int64
    if dbLoadError := db.LoadFromDatabase("count(distinct users)", &userCountInt64); dbLoadError != nil {
        return 0, fmt.Errorf("failed to load user count: %s", dbLoadError)
    }
    userCount = int(userCountInt64)
    return userCount, nil
}

// Good - clear and concise
func (db *DB) UserCount() (int, error) {
    var count int64
    if err := db.Load("count(distinct users)", &count); err != nil {
        return 0, fmt.Errorf("failed to load user count: %s", err)
    }
    return int(count), nil
}

Variable Names

This reference provides detailed guidance on naming variables in Go, covering scope-based naming, single-letter conventions, and avoiding type redundancy.

Length Proportional to Scope

Advisory: Short names for small scopes, longer names for large scopes.

// Good - short scope, short name
for i := 0; i < len(items); i++ {
    process(items[i])
}

// Good - larger scope, clearer name
func processOrders(orders []*Order) error {
    pendingOrders := filterPending(orders)
    // ... 20+ lines of processing ...
    return nil
}

Single-Letter Variables

Advisory: Use single letters only when meaning is obvious.

Appropriate uses:

• Loop indices: i, j, k
• Coordinates: x, y, z
• Receivers: one or two letters
• Common types: r for io.Reader, w for io.Writer
• Short loops: for _, n := range nodes

// Good - familiar conventions
func Copy(w io.Writer, r io.Reader) (int64, error)

for i, v := range values {
    process(v)
}

// Bad - unclear single letters
func Process(a, b, c string) error  // what are a, b, c?

Avoid Type in Variable Name

Advisory: Don't include the type in the variable name.

When disambiguating multiple forms, use meaningful qualifiers:

// Good - meaningful distinction
limitRaw := r.FormValue("limit")
limit, err := strconv.Atoi(limitRaw)

// Also good
limitStr := r.FormValue("limit")
limit, err := strconv.Atoi(limitStr)

Prefix Unexported Globals with _

Source: Uber Go Style Guide

Prefix unexported top-level vars and consts with _ to clarify when they are used that they are global symbols.

Rationale: Top-level variables and constants have package scope. Using a generic name makes it easy to accidentally shadow the value in a different file.

// Bad - hard to distinguish from local variables
const (
    defaultPort = 8080
    defaultUser = "user"
)

func Bar() {
    defaultPort := 9090  // shadows global, no compile error
    fmt.Println("Default port", defaultPort)
}

// Good - clearly global
const (
    _defaultPort = 8080
    _defaultUser = "user"
)

Exception: Unexported error values use the err prefix without underscore:

var errUserNotFound = errors.New("user not found")
var errInvalidInput = errors.New("invalid input")