loading...

Go - Considering package name.

takakd profile image Takahiro Kudo ・1 min read

I was considering the package name of golang today.
This package provides utility functions of operating HTTP.

At first, mypackage/utils
This is not good because "Avoid meaningless package names." is given as a bad here.

Next, mypackage/http or mypackage/httputil
These naming are also bad because "Avoid unnecessary package name collisions" is given as a bad too.

Finally, mypackage/apphttputils
I chose this.

If I use packages only in my application, do I not need to think?

Reference

https://blog.golang.org/package-names

Discussion

markdown guide
 

If I use packages only in my application, do I not need to think?

Name them so that anyone can understand.

If you have an internal package http (let's assume that's the best name somehow) under internal/ packages folder than you can just give in an alias during an import.

If the package is intended to be used (can be used) by other dev's you better think of those things you've mentioned but in the end it's their job to keep their code clean.

 

Oh, internal/ is easy to understand.
That's a good idea, I thought too.
Thanks for your feedback!

 

github.com/golang-standards/projec...

This repo has a layout example for Go application projects. We often use it within our team. Get a look!

Thank you for introducing helpful resources.
I'll try it!

 

Maybe mypackage/myhttp, mypackage/httpext meaning ext for extensions/extended?

 

Thanks, I didn't notice "ext".
I thought "ext" better than "utils".