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?
Top comments (6)
Name them so that anyone can understand.
If you have an internal package
http(let's assume that's the best name somehow) underinternal/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/httpextmeaningextfor extensions/extended?Thanks, I didn't notice "ext".
I thought "ext" better than "utils".