struct and class semantics aren't equivalent but they are similar. Which is why I think the rule "avoid -er" is relevant. If you're struggling to name something then you probably don't know what it is and what it needs to do.
I'm not advocating going to the Java extreme of fifty syllable names. Rather I'm siding with the principle that poor names are a smell of they don't fit or are buckets for random bits of code (eg util). On Wed, 13 Jul 2016 at 00:26, Thomas Bushnell, BSG <tbushn...@google.com> wrote: > That's advice for a very different style of language than Go. > > Go does not have "objects" in the sense of that post. A Go interface, for > example, does not "have lots of instance variables, lots of arguments, and > pass lots of data around probably." > > A class is not a struct is not a Go interface. > > Thomas > > On Tue, Jul 12, 2016 at 4:23 PM Nathan Fisher <nfis...@junctionbox.ca> > wrote: > >> There's a good oop blog article on the caveats of naming classes (struct) >> ending in -er. >> >> http://objology.blogspot.co.uk/2011/09/one-of-best-bits-of-programming-advice.html?m=1 >> >> I know the reader/writer interface kind of flies in the face of this but >> I think that's partly associated with it being an interface and its focus >> on one method. >> >> Personally if it's RESTy I'd opt for BlahResource where Blah is the >> resource that it manages which will probably map to an underlying >> serialisable struct with additional REST elements (eg next, self, etc). >> >> On Tue, 12 Jul 2016 at 17:41, Sam Whited <s...@samwhited.com> wrote: >> >>> On Tue, Jul 12, 2016 at 9:19 AM, Rayland <guianul...@gmail.com> wrote: >>> > When does it make sense for a package to be named in plural? For >>> example, >>> > I'm currently working on a MVC framework and for me it makes sense to >>> have a >>> > "controller" package as opposed to "controllers", but I saw that Beego >>> > prefers plural for the same case. >>> >>> Generally speaking, try to consider how your users will write things >>> that use your package and not what's actually in it. For instance, >>> which makes the better API: >>> >>> controller.New() >>> >>> or: >>> >>> controllers.NewController() >>> >>> The second is redundant, so I'd argue that the first one will look >>> better in your users code. However, given the example: >>> >>> byte.Split(b []byte) >>> >>> vs. >>> >>> bytes.Split(b []byte) >>> >>> the second may be more expected because you're operating on a collection. >>> >>> Of course, both of these are just my opinion, but it's just to >>> illustrate how I generally think about picking a name. Instead of >>> "what will my code in the package look like" think "what will my users >>> write using this package?" >>> >>> —Sam >>> >>> -- >>> 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. >>> >> -- >> 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. >> > -- 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.
