35

I have a codebase where one file contains quite a lot of Structs, Interfaces and Variables in the same file as functions and I'm not sure if I need to seperate this into separate files with appending filename. So for example accounts.go will be accounts_struct.go and accounts_interface.go with struct and interface respectively.

What would be a good approach for the file organisation when you have growing codebase for Structs, Variables and Interfaces?

Liam
  • 27,717
  • 28
  • 128
  • 190
Passionate Engineer
  • 10,034
  • 26
  • 96
  • 168
  • 1
    I feel like this is too broad... but my advice is think about what knowledge your code has and see if you can divide it into smaller chunks that have less knowledge. Don't arbitrarily decide to put all the structs in one file, that's weird. – David Grayson Oct 07 '14 at 05:14
  • 1
    In almost all cases so far (except, really, the very very front end of web apps) I have been able to divide a lot of my code into self contained, re-usable packages. You should see if that is possible with your code too. – Simon Whitehead Oct 07 '14 at 06:20

2 Answers2

27

A good model to check out is the source code of Go itself: http://golang.org/src
(in addition of the official "Effective Go")

You will see that this approach (separating based on language items like struct, interface, ...) is never used.

All the files are based on features, and it is best to use a proximity principle approach, where you can find in the same file the definition of what you are using.
Generally, those features are grouped in one file per package, except for large ones, where one package is composed of many files (net, net/http)

If you want to separate anything, separate the source (xxx.go) from the tests/benchmarks (xxx_test.go)

As Thomas Jay Rush adds in the comments

Sometimes source code is automatically generated -- especially data structure definitions.
If the data structures are in the same file as the hand-wrought code, one must build capacity to preserve the hand-wrought portion in the code-generation phase.
If the data structures are separated in a different file, then inclusion allows one to simply write the data structure file without worry.

Dave Cheney offers an interesting perspective in "Absolute Unit (Test) @ LondonGophers" (March 2019)

You should take a broader view of the "unit" under test.
The units are not each internal function you write, but a whole package. Specifically the public API of a package.

Organizing your files to facilitate testing their Public API is a good idea.
accounts_struct_test.go would not, in that regards, make much sense.

See also "How I organize packages in Go" by Bartłomiej Klimczak

Sometimes, a few handlers or repositories are needed.
For example, some information can be stored in a database and then sent via an event to a different part of your platform. Keeping only one repository with a method like saveToDb() isn’t that handy at all.
All of elements like that are split by the functionality: repository_order.go or service_user.go.
If there are more than 3 types of the object, there are moved to a separate subfolder.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Great! Is it best to put Structs at the top or directly above func? – Passionate Engineer Oct 07 '14 at 06:38
  • @PassionateDeveloper I prefer on top, defining the various type I use (struct, func, aliases, ...), especially if those are public type (with an uppercase). But for internal private type (lowercase), I define them in the middle of the code, just before using them. – VonC Oct 07 '14 at 06:42
  • @PassionateDeveloper in any case, golint (https://github.com/golang/lint) and go vet are your friends. https://blog.splice.com/going-extra-mile-golint-go-vet/ – VonC Oct 07 '14 at 06:43
  • While certainly canonical, the above answer ignores the fact that sometimes source code is automatically generated -- especially data structure definitions. If the data structures are in the same file as the hand-wrought code, one must build capacity to preserve the hand-wrought portion in the code-generation phase. If the data structures are separated in a different file, then inclusion allows one to simply write the data structure file without worry. I'm not arguing for a change in the way people write `go` code, just saying that a lot of my code is auto-generated. – Thomas Jay Rush Jun 27 '19 at 12:49
  • 1
    @ThomasJayRush Good point. I have included your answer in the question for more visibility. – VonC Jun 27 '19 at 13:35
  • 1
    Isn't the whole point of Go about thinking in terms of the functionality and not worry too much about "how could we solve this problem using Go"? I think the style guide is all that we may ever need: https://golang.org/doc/effective_go If it makes sense to have interfaces and structs in different files for a project, there is no reason to not do so. Go's source code might be a good guide if we are writing a compiler – Sreram Aug 19 '21 at 18:09
  • @Sreram Good point. I have added a link to "Effective Go" in the answer. – VonC Aug 19 '21 at 19:50
24

Here is my mental model for designing a package.

a. A package should encompass one idea or concept. http is a concept, http client or http message is not.

b. A file in a package should encompass a set of related types, a good rule of thumb is if two files share the same set of imports, merge them. Using the previous example, http/client.go, http/server.go are a good level of granularity

c. Don't do one file per type, that's not idiomatic Go.

Dave Cheney
  • 5,575
  • 2
  • 18
  • 24
  • +1. I agree. That reminds me of some of the advices I found at the time in http://stackoverflow.com/a/14870666/6309. – VonC Oct 07 '14 at 07:46