In this section, we’ll offer some advice on how to follow Go’s distinctive conventions for naming packages and their members.
When creating a package, keep its name short, but not so short as to
be cryptic.
The most frequently used packages in the standard library are named
bufio, bytes, flag, fmt, http,
io, json, os, sort, sync, and
time.
Be descriptive and unambiguous where possible.
For example, don’t name a utility package util when a name such
as imageutil or ioutil is specific yet still concise.
Avoid choosing package names that are commonly used for related local
variables, or you may compel the package’s clients to use
renaming imports, as with the path package.
Package names usually take the singular form.
The standard packages bytes, errors, and strings
use the plural to avoid hiding the corresponding predeclared
types and, in the case of go/types, to avoid conflict with a
keyword.
Avoid package names that already have other connotations.
For example, we originally used the name temp for the
temperature conversion package in Section 2.5, but
that didn’t last long.
It was a terrible idea because “temp” is an almost universal synonym
for “temporary.”
We went through a brief period with the name temperature, but
that was too long and didn’t say what the package did.
In the end, it became tempconv, which is shorter and parallel
with strconv.
Now let’s turn to the naming of package members.
Since each reference to a member of another package uses a qualified
identifier such as fmt.Println, the burden of describing the package
member is borne equally by the package name and the member name.
We need not mention the concept of formatting in Println
because the package name fmt does that already.
When designing a package, consider how the two parts of a
qualified identifier work together, not the member name alone.
Here are some characteristic examples:
bytes.Equal flag.Int http.Get json.Marshal
We can identify some common naming patterns. The strings package
provides a number of independent functions for manipulating strings:
package strings
func Index(needle, haystack string) int
type Replacer struct{ /* ... */ }
func NewReplacer(oldnew ...string) *Replacer
type Reader struct{ /* ... */ }
func NewReader(s string) *Reader
The word string does not appear in any of their names. Clients refer to
them as strings.Index, strings.Replacer, and so on.
Other packages that we might describe as single-type packages,
such as html/template and
math/rand, expose one principal data type plus its methods, and often a
New function to create instances.
package rand // "math/rand"
type Rand struct{ /* ... */ }
func New(source Source) *Rand
This can lead to repetition, as in template.Template or
rand.Rand, which is why the names of these kinds of packages
are often especially short.
At the other extreme, there are packages like net/http that
have a lot of names without a lot of structure, because they perform a
complicated task.
Despite having over twenty types and many more functions, the package’s most
important members have the simplest names:
Get, Post, Handle, Error, Client,
Server.