Interface naming convention -er vs. -or

[Brendan Tracey]

Just curious, if I have an interface which contains only the Actuate method, should it be an Actuater or an Actuator?

[Rob Pike]

Actuator.

-rob

[Nate Finch]

Proper English is always preferable.

On Feb 27, 2013 7:11 PM, "Brendan Tracey" <tracey....@gmail.com> wrote:

Just curious, if I have an interface which contains only the Actuate method, should it be an Actuater or an Actuator?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[bryanturley]

I have occasionally used -able as well, thought I can't find it now to give a full example...

[Dan Kortschak]

I'm glad I'm not alone in this. I use a 'Comparable' interface in biogo.llrb, since I figured the items are comparable, rather than just things that compare something.

[Rob Pike]

Both work. Vulnerable. Miserable. Intolerable.

-rob

[bryanturley]

I wanted to use Tablable as an example, but only has a joke ;)

[Dan Kortschak]

And in the Australian context, Ropeable.

[Camilo Aguilar]

I'm still struggling with naming interfaces in Golang. I initially thought it was my fault not being able to come up with names fitting correctly into the "er" convention, but then I found out the same problem in Golang source code. It seems like this whole interface naming convention is source of a lot of confusion even for Golang core developers. For example:

• Queryer interface: https://github.com/jnwhiteh/golang/blob/master/src/pkg/database/sql/driver/driver.go#L64. Is it ok that it is not proper English?
  
• Conn interface: https://github.com/jnwhiteh/golang/blob/master/src/pkg/database/sql/driver/driver.go#L83. Why not Conner?
  
• Result interface: https://github.com/jnwhiteh/golang/blob/master/src/pkg/database/sql/driver/driver.go#L102 Why not Resulter?
  

It would be extremely helpful if somebody could thoroughly clarify more about this topic either through a blog post or through this email thread. It could be that we users are approaching code design the wrong way in Golang, if so, it would be also great if somebody can explain what the mindset should be when designing code in Golang. 

This has been the only pain point for me in Golang, the rest has been a breeze. Golang is awesome and please keep up the good work.

Best, 

Camilo Aguilar

http://github.com/c4milo

  

On Thu, Feb 28, 2013 at 3:52 PM, Dan Kortschak <dan.ko...@adelaide.edu.au> wrote:

And in the Australian context, Ropeable.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Camilo Aguilar

Software Engineer

http://github.com/c4milo

[voidl...@gmail.com]

Since interfaces naturally describe capabilities I personally would go with Queryable over Queryer.
What is Query-able? Something that is able to query. Queryer sounds like something that asks questions rather than provides answers.

I think the nouns like Connection and Result are OK as well.

But it is pretty common sense what these interfaces do (you can always read the interface def. after all), so as long as your standardize sufficiently to make yourself happy within your own projects, I don't see what the big deal is.

On Monday, October 28, 2013 2:36:36 PM UTC-5, Camilo Aguilar wrote:

I'm still struggling with naming interfaces in Golang. I initially thought it was my fault not being able to come up with names fitting correctly into the "er" convention, but then I found out the same problem in Golang source code. It seems like this whole interface naming convention is source of a lot of confusion even for Golang core developers. For example:

• Queryer interface: https://github.com/jnwhiteh/golang/blob/master/As long as your standardize within your own codesrc/pkg/database/sql/driver/driver.go#L64. Is it ok that it is not proper English?
  

• Conn interface: https://github.com/jnwhiteh/golang/blob/master/src/pkg/database/sql/driver/driver.go#L83. Why not Conner?
  
• Result interface: https://github.com/jnwhiteh/golang/blob/master/src/pkg/database/sql/driver/driver.go#L102 Why not Resulter?
  

It would be extremely helpful if somebody could thoroughly clarify more about this topic either through a blog post or through this email thread. It could be that we users are approaching code design the wrong way in Golang, if so, it would be also great if somebody can explain what the mindset should be when designing code in Golang. 

This has been the only pain point for me in Golang, the rest has been a breeze. Golang is awesome and please keep up the good work.

Best, 

Camilo Aguilar

http://github.com/c4milo

  

[Jan Mercl]

On Mon, Oct 28, 2013 at 9:02 PM, <voidl...@gmail.com> wrote:
> Since interfaces naturally describe capabilities I personally would go with
> Queryable over Queryer.
> What is Query-able? Something that is able to query. Queryer sounds like
> something that asks questions rather than provides answers.

.*able is about what something is able to do.

.* is what something is.

Readable vs Reader, for example. IOW, the 'able' suffix is IMHO a
misconception. We have sales force or service providers, not deal
"closeable" persons and providable services, for example.

-j

[Camilo Aguilar]

do you see? this is what I mean when I say this topic generates a lot of confusion :). 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Kevin Gillette]

On Monday, October 28, 2013 2:02:46 PM UTC-6, Tylor Arndt wrote:

Since interfaces naturally describe capabilities I personally would go with Queryable over Queryer.

If there wasn't a concrete type called Query, I'd just call the interface Query, since Query is both a verb and a noun. Otherwise, I'd call it Queryer.

 

On Monday, October 28, 2013 2:36:36 PM UTC-5, Camilo Aguilar wrote:

• Queryer interface: https://github.com/jnwhiteh/golang/blob/master/As long as your standardize within your own codesrc/pkg/database/sql/driver/driver.go#L64. Is it ok that it is not proper English?

Yes. When proper English is available, use it (e.g. Conveyor instead of Conveyer for an interface with a Convey method).

• Conn interface: https://github.com/jnwhiteh/golang/blob/master/src/pkg/database/sql/driver/driver.go#L83. Why not Conner?

 

When an interface has multiple unrelated methods (Prepare, Begin, and Close are unrelated), then the interface is better named and described in terms of what it is abstractly, rather than what implementers of it can do. Conversely, ReadWriters can read and write, and those operations are related, thus it makes sense to use them as the basis for the interface name.

• Result interface: https://github.com/jnwhiteh/golang/blob/master/src/pkg/database/sql/driver/driver.go#L102 Why not Resulter?

Same.

The main lesson (as with anything in programming or life) is to not treat all rules as absolute, since there are always reasonable exceptions. Interface naming isn't even a rule -- it's a convention -- so it's reasonable for there to be confusion and disagreement (especially when it's treated like a rule), but it also lends more flexibility to make appropriate choices.

[Camilo Aguilar]

Reasonable answers Kevin, thank you!

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Keith Rarick]

On Mon, Oct 28, 2013 at 12:36 PM, Camilo Aguilar
<camilo....@gmail.com> wrote:
> I'm still struggling with naming interfaces in Golang. I initially thought
> it was my fault not being able to come up with names fitting correctly into
> the "er" convention, but then I found out the same problem in Golang source
> code. It seems like this whole interface naming convention is source of a
> lot of confusion even for Golang core developers.

The rule is "choose clear, meaningful names", not "interface
names should end in -er". The -er convention is to help out
when following the original rule, and to help you choose
among several reasonable alternatives, avoiding needless
inconsistency.

Also, the convention is to use -er for interfaces with just a
single method, not for all interfaces, and it works best when
the method name is a verb. You take the method name and
add -er to form a noun.

So we can answer these questions by looking at the
underlying principle: if the -er name is unclear, don't use it.
If -or gives you a real English word, use that instead.
If the method name isn't a verb, you have to think harder.
If the interface has several methods, the convention doesn't
apply, you have to choose a name some other way.

> Queryer interface:

> Is it ok that it is not proper English?

For Queryer, I might have chosen Querier.

Which do you think is clearer?

> Conn interface:

> Why not Conner?
> Result interface:

> Why not Resulter?

Conn is already a noun, and it has several methods.
Same goes for Result.

(If there were some other type 'interface { Conn() }',
then I'd consider Conner as its name, but Conn isn't
a verb and I find Conner awkward.)

[Aram Hăvărneanu]

Just for fun:

: iridium:aram; lsr go/src/{cmd,pkg} | grep 'go$' | grep -v test |
xargs egrep '^type [a-zA-Z].*interface {' | awk '{ print $2 }' | sort
| uniq | wc -l
125

: iridium:aram; lsr go/src/{cmd,pkg} | grep 'go$' | grep -v test |
xargs egrep '^type [a-zA-Z].*interface {' | awk '{ print $2 }' | sort
| uniq | grep 'er$' | wc -l
56

: iridium:aram; lsr go/src/{cmd,pkg} | grep 'go$' | grep -v test |
xargs egrep '^type [a-zA-Z].*interface {' | awk '{ print $2 }' | sort
| uniq | grep 'or$' | wc -l
4

Let's look only at exported interfaces:

: iridium:aram; lsr go/src/{cmd,pkg} | grep 'go$' | grep -v test |
xargs egrep '^type [A-Z].*interface {' | awk '{ print $2 }' | sort |
uniq | wc -l
95

: iridium:aram; lsr go/src/{cmd,pkg} | grep 'go$' | grep -v test |
xargs egrep '^type [A-Z].*interface {' | awk '{ print $2 }' | sort |
uniq | grep 'er$' | wc -l
46

: iridium:aram; lsr go/src/{cmd,pkg} | grep 'go$' | grep -v test |
xargs egrep '^type [A-Z].*interface {' | awk '{ print $2 }' | sort |
uniq | grep 'or$' | wc -l
3

: iridium:aram; lsr go/src/{cmd,pkg} | grep 'go$' | grep -v test |
xargs egrep '^type [a-zA-Z].*interface {' | awk '{ print $2 }' | sort
| uniq
AEAD
Addr
Auth
BinaryMarshaler
BinaryUnmarshaler
Block
BlockMode
ByteOrder
ByteReader
ByteScanner
ByteWriter
ClientCodec
CloseNotifier
Closer
Color
ColumnConverter
Conn
CookieJar
Curve
Decl
Drawer
Driver
Error
Execer
Expr
File
FileInfo
FileSystem
Flusher
Formatter
Getter
GoStringer
GobDecoder
GobEncoder
Handler
Hash
Hash32
Hash64
Hijacker
Image
Interface
Listener
Load
Locker
Marshaler
MarshalerAttr
Model
Node
PacketConn
PalettedImage
PublicSuffixList
Quantizer
Queryer
ReadCloser
ReadSeeker
ReadWriteCloser
ReadWriteSeeker
ReadWriter
Reader
ReaderAt
ReaderFrom
ResponseWriter
Result
RoundTripper
RoutingMessage
Rows
RuneReader
RuneScanner
ScanState
Scanner
Seeker
ServerCodec
Signal
Sockaddr
Source
State
Stmt
Stream
Stringer
TextMarshaler
TextUnmarshaler
Tx
Type
Unmarshaler
UnmarshalerAttr
Value
ValueConverter
Valuer
Var
Visitor
WriteCloser
WriteSeeker
Writer
WriterAt
WriterTo
boolFlag
cbcMode
countProfile
dataFormat
dnsRR
dnsStruct
error
finalCloser
gobType
handshakeMessage
input
keyAgreement
macFunction
netaddr
opaquer
reader
replacer
runeUnreader
serverConn
sniffSig
sockaddr
stringWriter
stringWriterIface
stringer
temporary
timeout
toolchain
writeFlusher
writeStringer
writer

--
Aram Hăvărneanu

[Camilo Aguilar]

Hey Keith, perfectly clear, thanks for the thorough answer. 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Camilo Aguilar]

Keith, to answer your question, Querier is definitely much better than Queryer. Also, for Execer I would personally prefer "Executor" if that makes sense.

[roger peppe]

One issue that came up for us was how to name
an interface that contains a method which is itself
named with an "er" suffix.

For example:

type Fooer interface {
Foo()
}

type X interface {
Fooer() Fooer
}

What do we name X in that scenario? For a brief time
(until I discovered it and made a noise) we used Fooerer!

Now we're using FooerGetter, which is an improvement
but still not great.

[luz...@gmail.com]

My opinion: Guidelines aren't dogma and don't replace the brain. Use the most appropriate name depending on the situation.

[Dan Kortschak]

I conjunction with an Undertaker.

[atomly]

What's the old statement?  "There are 2 hard problems in CS: caching, naming and off-by-1 errors."

:: atomly ::

[ ato...@atomly.com : www.atomly.com  : http://blog.atomly.com/ ...
[ atomiq records : new york city : +1.347.692.8661 ...
[ e-mail atomly-new...@atomly.com for atomly info and updates ...

[atomly]

On Mon, Oct 28, 2013 at 5:39 PM, Keith Rarick <k...@xph.us> wrote:

(If there were some other type 'interface { Conn() }',
then I'd consider Conner as its name, but Conn isn't
a verb and I find Conner awkward.)

How about Connector?