IMO it's simpler to start with all you code in a single package and only break something out when you find three or more cases where the code could be reused.
Some other markers I use to guide breaking the code up into separate packages are if you find you have written a significant amount of helper code for a function which isn't directly related to the program's purpose. Currently I'm writing a tool that checks in the company LDAP directory for group membership then issues an SSL client certificate for access to a HTTPS service. In that case the LDAP and ssl cert generation code is sufficiently unrelated to the goal of the tool itself (LDAP and ssl are just implentation details) that I felt it was a good idea to move them into their own internal packages. It also helped that I would write the package doc in the form "package ldap provides helpers to check group membership", or something like that. Imo, all things equal, when you would in other languages use a package, use a file in go. One rule of thumb I use is to group code with common imports into one file, for example all the code that imports the bet package goes in conn.go, all the code that deals with text processing goes in the message.go file, and so on. This also helps with testing as the only code that knowns anything about networks is Conn.go, so message_test.go won't have any cause to mock a net.Conn. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
