Rule for GoLang Interface name and its number of methods

Question

Ones I had a discussion at work about correlation between interface name and number its methods. In particular, there is an unwritten rule about an interface with postfix notation ending with er in its name. The rule says such an interface should have one method contained.

Let's jump into an example. In the standard Go lang library, there is Pusher interface that does one thing "Push initiates an HTTP/2 server push". Here is its definition:

type Pusher interface {
  Push(target string, opts *PushOptions) error
}

https://golang.org/pkg/net/http/#Pusher

Good example. However, some colleague defended his implementation that contained more than two methods with er in name's postfix. The main argument was that there are stdlib's interfaces that violates such a rule. He referred to interface ReadCloser.

Looking at its definition:

type ReadCloser interface {
        Reader
        Closer
}

https://golang.org/pkg/io/#ReadCloser

I can say its wrong assumption. Interface embed in itself two other interfaces. How I interpret that? The rule is not violated.

How will you interpret such a case?

Answer 1

This question is possibly going to get closed, either because it's deemed opinion based, or not code related, or whatever...

However, golang being deemed quite opinionated, and because I deem standards very important, I'll chip in with my take on the unwritten rule, and how I'd reconcile, essentially why the ReadCloser is fine, but some other er interfaces might not be.

---

I'd interpret the ReadCloser not to violate the "rule" (I'd call it a convention more like). I have a number of arguments why I'd say it's not violating the convention:

1. It's not a standalone interface

The ReadCloser interface isn't a self-contained interface. It's a composed interface. It's name reflects this. It concatenates Read and Close (the 2 functions in the interface you're after), and adds the er suffix. How both functions are implemented, and where they come from is irrelevant to the interface. If you read something, chances are you'll need to close the resource, too. It only makes sense to combine the two interfaces, so you can use the type that guarantees both Reader and Closer functionality to be available.

2. Names mustn't stutter

Much like the guidelines WRT package names stutter is to be avoided. Especially if it doesn't add any value. Technically, one could argue that the interface should be called ReaderCloser, but does that name communicate anything that isn't conveyed by the name ReadCloser? Surely not. The latter doesn't repeat the suffix, and reads easier.

3. The er interfaces and CamelCasing

The examples of single-function er interfaces like Stringer, or Publisher are indeed cut & dry. A Stringer contains the String function. End of story. Same as the Publisher interface.

You'll note that the ReadCloser interface is CamelCased, suggesting it's a composit type. Just split the name on UpperCase characters, and add the suffix to each part. If the parts are bona-fide er interfaces, and the composite interface makes sense (cf point 1: if you read, chances are you'll need to close), then it's a valid composite interface.

Examples of an invalid er interface would be:

type FileReader interface {
    ReadCloserer
    ScanDir(string) ([]string, error)
    IsFile(string) bool
    Open(string, string) error
    // and so on
}

This interface contains too many BS functions to be packed into a FileReader interface.