Why Go Uses ‘er’ and ‘able’ Suffixes: Naming Conventions Explained

Interface Naming with er Suffix

Go interfaces are typically named with the er suffix to describe the single method they expose. The name directly conveys the behavior that an implementation must provide.

type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

type Closer interface {
    Close() error
}

Capability Naming with able Suffix

When an interface represents a broader capability rather than a single action, the able suffix is sometimes used. It signals that a type possesses a particular ability, such as being serializable or convertible.

type Stringer interface {
    String() string
}

type JSONMarshaler interface {
    MarshalJSON() ([]byte, error)
}

Guidelines for Choosing Names

Single‑method interfaces : Prefer the er suffix (e.g., Reader, Writer, Closer).

Capability interfaces : Use able when the interface groups several related methods or expresses a property (e.g., Stringer, JSONMarshaler).

Brevity vs. clarity : If a concise name already conveys intent, omit the suffix. Go’s philosophy favors short, expressive names.

Consistency : Apply the same convention across a codebase to aid readability and onboarding.

Benefits of Consistent Naming

Improved readability : Developers can infer an interface’s purpose from its name without inspecting the method set.

Enhanced maintainability : Uniform naming reduces cognitive load during code reviews and refactoring.

Clear intent : Suffixes act as a lightweight form of documentation, making API contracts explicit.

Practical Application

When designing a new package, start by asking whether the interface represents a single action ( er) or a broader capability ( able). Draft the interface, then evaluate the name:

Does the name describe the behavior succinctly?

Is the er or able suffix adding clarity or redundancy?

Can the interface be merged with an existing one to avoid unnecessary proliferation?

Following these steps helps keep the API surface small while preserving expressive power.