To me having packages in an application is already a code smell, my requirement is each non-main package should provide very specific functionality that could be shared between applications.
I remember the Quake source code having most everything in one directory of C files, and I think Go application development works well with that approach. Application components should be expressed as functions and types separated into carefully named files, not packages, in my opinion. There’s a community Go DNS library that was shared here recently that took this approach too far in my opinion though. In that case the DNS specification logic should be in a separate package. Maybe consensus in other languages applied to the same application could be good sources of patterns. I’m not convinced the Go community is old enough to have consensus on much, not even the language itself since Go 2 is happening. Your trials are the most important today, apply your best logic to the problem and pick the best language features, then report back in proposal issues and with experience reports. Effective Go is good documentation that may cover the "right way" in many cases: https://golang.org/doc/effective_go.html Matt On Wednesday, January 17, 2018 at 5:28:34 PM UTC-6, Keith Brown wrote: > > is there a page such as "https://github.com/yksz/go-design-patterns"; I > can refer to for golang design-patterns? I wish there were some official > ones, which can help language newbies and give them confidence that what > they are doing is the "right way". I understand it depends on the problem > but would be great if something was there. > > > On Saturday, December 16, 2017 at 2:52:14 AM UTC-5, dc0d wrote: >> >> I've been reading the other day: "having a model package, is considered >> a code smell, in Go". >> >> 1 - Why? >> 2 - If so, what approach should be chosen? >> 3 - And how? (In Go code, Go features to employ, Patterns (small/big >> projects), etc) >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
