No , it's not golang-standards
abshammeri opened this issue · 17 comments
This repo owner confuses beginners (golang-standards), actually its' not a standard. It's just an opinion of a group of coders and historical reasons as it's mentioned in the README and part of the project structure is a bad practice ( like vendor or pkg directories, we have something called mods now!) . I suggest to move this project to another organization called "golang-non-standard" or remove it.
@abshammeri is there something like a standard? And if yes, where can I find it?
@develerik No, to the best of my knowledge there is no standard for this.
@abshammeri so this is a try to "standardize" this, nope?
I’ve always found the official guidelines comprehensive enough for most projects.
I’ve always found the official guidelines comprehensive enough for most projects.
I cannot find in official guidilines you linked something about directories structure. Can you link me something?
+1
@abshammeri thank you for sharing your thoughts! It's great! Your definition of standard is a bit too rigit though. There are official standards and there are de facto standards based on the historical and emerging patterns in the community. It's also ok not to like the vendor or pkg patterns. Feel free to do whatever makes sense for you. Just because you don't use/like those patterns doesn't mean others don't find them useful. And with vendoring it's still an officially supported feature even with go modules (using the go mod vendor command).
@develerik , @frederikhors the exact directory structure will be heavily influenced by the nature of the application you have (a web app structure will look different than a backend microservice app). This repo captures a few basic go-specific directories you might have (e.g., /cmd) and a number of generic directories you'd want to have in a big enough project. I highly recommend looking at the references at the beginning of the main README doc (e.g., by Kat Zien where she explores different way to structure your app and app packages). Effective Go mentioned by @ilazakis is awesome too though it's more about the Go code itself!
Patterns can be moderately evolved, just like software architecture.
Before there is no standard, it is best to refer to the layout, add your own thinking and adapt to your own project.
+1
I think, better name for this project is golang-best-practice, than golang-(non-)standard. Because, for my self, this folder's structure is best entry point for how to name this? to start new Golang project.
Not Holy Grail, but still better than nothing! 👍
I just started 2 days ago in Go, I agree with @koddr it may no be the best name, but it is definitely better than nothing.
As a newbie, I will appreciate if you folks align in such a project rather than bite-shedding and fighting over something that hurts the ecosystem from the perspective of an outsider.
I much rather align with the sentiment, than using my time thinking about this stuff, or even worst, disagree with a co-worker.
Maybe being proactive, and collaborative instead of fighting over this would be a better solution 🤷♂
I will appreciate as a newbie.
interesting
Golang is a community-driven language, and this repo is a community de-facto standard.
As a beginner, you will see this in many real projects (and in many companies, it's a real standard now), you also will be asked about it on interviews.
There is no reason to not mention it as a standard now, because it become a real standard.
this repo is a community de-facto standard.
To call this a "standard" suggests that it is the product of a standards body. This isn't such a thing; the entire org is literally just @kcq. The only reason there is a github org named "golang-standards" is that if he put it on his personal github account the SEO would not be as good and it would not get as many stars.
Broadly, it should not be possible for an individual outside of the Go team to create a github org called "golang-standards", as that name very clearly suggests to the reader that the organization is affiliated with the Go team.
If you want to see a recent repo of how people are structuring actual projects, Google's exposure notification server for covid contact tracing is open-source and uses a pretty conventional project structure:
Google's exposure notification server for covid contact tracing is open-source and uses a pretty conventional project structure
The util and pkg are unfortunate though
https://github.com/google/exposure-notifications-server/tree/main/pkg/util
While util is specifically pointed as bad name:
https://go.dev/blog/package-names#bad-package-names
the pkg is some kind of cargo-cult which continues to live over "generations"
https://twitter.com/bradfitz/status/1039512487538970624
Back-linking to #52