Plurality of package naming

[Rayland]

When does it make sense for a package to be named in plural? For example, I'm currently working on a MVC framework and for me it makes sense to have a "controller" package as opposed to "controllers", but I saw that Beego prefers plural for the same case.

[roger peppe]

I prefer the singular form unless pushed towards the plural for
some reason (for example, because we want both plural and
singular forms).

The plural package names in the stdlib are generally there
because the singular form is a reserved word or
keyword (strings, types, errors, bytes).

> --
> 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/d/optout.

[Sam Whited]

Generally speaking, try to consider how your users will write things
that use your package and not what's actually in it. For instance,
which makes the better API:

controller.New()

or:

controllers.NewController()

The second is redundant, so I'd argue that the first one will look
better in your users code. However, given the example:

byte.Split(b []byte)

vs.

bytes.Split(b []byte)

the second may be more expected because you're operating on a collection.

Of course, both of these are just my opinion, but it's just to
illustrate how I generally think about picking a name. Instead of
"what will my code in the package look like" think "what will my users
write using this package?"

—Sam

[Sameer Ajmani]

The package names blog post may be useful, though it does not provide specific guidance on singular vs plurals:
https://blog.golang.org/package-names

[Nathan Fisher]

There's a good oop blog article on the caveats of naming classes (struct) ending in -er.
http://objology.blogspot.co.uk/2011/09/one-of-best-bits-of-programming-advice.html?m=1

I know the reader/writer interface kind of flies in the face of this but I think that's partly associated with it being an interface and its focus on one method.

Personally if it's RESTy I'd opt for BlahResource where Blah is the resource that it manages which will probably map to an underlying serialisable struct with additional REST elements (eg next, self, etc).

[Thomas Bushnell, BSG]

That's advice for a very different style of language than Go.

Go does not have "objects" in the sense of that post. A Go interface, for example, does not "have lots of instance variables, lots of arguments, and pass lots of data around probably."

A class is not a struct is not a Go interface.

Thomas

[Nathan Fisher]

struct and class semantics aren't equivalent but they are similar. Which is why I think the rule "avoid -er" is relevant. If you're struggling to name something then you probably don't know what it is and what it needs to do.

I'm not advocating going to the Java extreme of fifty syllable names. Rather I'm siding with the principle that poor names are a smell of they don't fit or are buckets for random bits of code (eg util).

[Thomas Bushnell, BSG]

They are similar, except for where they are different.

Here, we're talking about interfaces, which are very different from struct and class naming conventions. An object has only one class in OOP, but in Go it is normal for a single type to implement many interfaces, including ones it doesn't even know exist.