liveBook · Manning

Package name

As explained in 100 Go Mistakes and How to Avoid Them

A package name is the identifier that names a software package and communicates the package's purpose to its users.

A package name identifies what a Go package provides. Choose a short, concise, expressive, single lowercase word rather than naming the package after its contents. section 2.12.2

Avoid these common package-naming mistakes:

  • Do not create a meaningless utility package named util, common, shared, or base; use an expressive name such as stringset. section 2.13
  • Do not force dozens of tiny packages or one huge package; balance cohesion, readability, and the meaning communicated by the name. section 2.12.2 section 2.13
  • Do not shadow a package name with a variable: redis := redis.NewClient() makes redis refer to the variable throughout its scope. section 2.14

Replace a generic utility name

A generic API such as util.NewStringSet("c", "a", "b") and util.SortStringSet(set) hides its purpose. Rename the package to stringset and shorten its functions: stringset.New("c", "a", "b") and stringset.Sort(set). A dedicated Set type can simplify the client further: set := stringset.New("c", "a", "b"); set.Sort().

Resolve a package collision

Prefer a distinct variable name: redisClient := redis.NewClient(). If redis must remain the variable name, alias the import instead: import redisapi "mylib/redis"; redis := redisapi.NewClient(). Avoid dot imports because removing the package qualifier can increase confusion. section 2.14

/net
    /http
        client.go
        ...
    /smtp
        auth.go
        ...
    addrselect.go
    ...

Browse a standard-library package layout to see how related capabilities receive focused package names. section 2.12.2

How 100 Go Mistakes and How to Avoid Them covers it

How deep it goes
Explains naming criteria, package granularity, API effects, and collision fixes through concrete Go examples.
Examples
Uses util versus stringset APIs, a typed Set, Redis client variables, and an import alias to demonstrate naming decisions.
What it assumes
Assumes familiarity with Go packages, exported identifiers, variables, and imports while reinforcing package-design judgment.
What you can do after
Apply naming and import-alias techniques to design clearer packages and diagnose package-variable collisions.
How it connects
Connects package names with package organization, API design, package imports, import aliases, and name collisions.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of 100 Go Mistakes and How to Avoid Them. The section links point to the parts of the book it draws on.