The "Effective Go" states:
By convention, one-method interfaces are named by the method name plus an -er suffix or similar modification to construct an agent noun:
Reader
,Writer
,Formatter
,CloseNotifier
etc.
bufio.io
package contains this:
// Reader implements buffering for an io.Reader object.
type Reader struct {
buf []byte
rd io.Reader
r, w int
err error
lastByte int
lastRuneSize int
}
Is it idiomatic having structs named like "*er"? Especially in this case it's a struct
with the same name as io.Reader
which is an interface.
If it's not in Effective Go or the specs then it's a matter of opinion really, I'd say it's fine as long as it makes sense.
Using bufio.Reader
or bytes.Reader
as an example, they make perfect sense to be named that way.
The comment type bufio.Reader struct
are important:
// Reader
implements buffering for an io.Reader
object.
The bufio packages adds:
It wraps an
io.Reader
orio.Writer
object, creating another object (Reader
orWriter
) that also implements the interface but provides buffering and some help for textual I/O.
Since bufio.Reader
isn't there to add any new service, but only to implements an io.Reader
in a buffered way, it makes sense to keep the name and just implement the functions: a struct
is enough.
For the user's point of view, it is a Reader
that he/she can uses wherever an io.Reader is required.