Now I’m gonna talk about package names and how to choose package names in the Go way.
The guidelines provided by Effective Go on naming packages are pretty good - the bottom line is that you should:
- Keep ‘em short and concise (and don’t worry about name collisions).
- Choose a name good enough to give context to your exported Interfaces, Structs and Function.
The first one is for readability. Name collisions hardly happens, and when they do, the importer of the package can make a decision and change the reference of the imported package. It’s not up to a package to avoid name collisions, but to its importers.
The second one is kinda tricky, but when you see the implementation of the Reader interface across packages, it’s easier to see the point:
In all of the three cases, the type is Reader and the package name is short, concise enough and it gives context to the content of the package.
When Go’s standard library gained an implementation of a Ring data structure, it gained a package named ring. Initializing a new ring was just a matter of calling ring.New(). This is normally how you should write your constructors.
Good package names are very important to writing a code that’s nice and easy to read. I also believe this blog post regarding package names is a great resource!
So, that pretty much sums up what I what to say. I strongly recommend reading the references!
Cool reference links⌗