Go: how many packages per project

Vote count:

0

While working on my Go project today, I realised I had ran into a small problem. I had a package that had a struct that held a pointer to a struct from another package. However, that package also made use of a struct from the other package. In C and C++, this wouldn't pose an issue, as I'd use a header guard. However, in Go, such a program won't compile due to infinite import recursion.

This made me wonder, are there too many packages in my project? Should I favour bigger packages? I've always been told that each package should be specifically focused on one thing.

Right now, my structure is like this.

game/                  <-- imports engine, needs to access the resource manager a lot
    video/             <-- rendering goes here
        renderer.go
        shader.go
        scene.go
        ...
    engine/            <-- imports video, file, etc
        root.go        <-- contains a Root struct, handles initialisation etc
        resource.go
        ...
    file/
        dds.go
        config.go
        resource_list.go
        script.go
        ...
    main.go
    ...

That said, here are my questions:

• How would you solve this? Would you combine the video and engine packages? Redesign your program so that video no longer depends on engine?


• How do you decide when it's appropriate to make a new package? Do you base it on functionality? Do you group it by category?


• How much use do you make of the main package? I personally tend to get out of it as quickly as possible, maybe because I'm too used to OOP.

asked 1 min ago

Jesse Brands

440

Go: how many packages per project