Interface names

Canonical guidance

• name interfaces for behavior
• prefer small interfaces near the consumer
• use conventional -er names when they fit naturally

Use when

• introducing a new abstraction
• extracting a dependency for tests
• reviewing exported interfaces

Avoid

• vague umbrella names
• naming an interface after its implementation detail
• giant interfaces with tiny behavior names

Preferred pattern

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

Anti-pattern

• type UserService interface { ...many unrelated methods... }

Explanation: This is tempting because broad names feel flexible, but vague interfaces weaken both design and call-site understanding.

Why

• interface names are most useful when they encode the exact behavior being depended on