组织代码的惯用方式

I feel the pending 'close question, too vague, opinions,...' but here goes.

How do I organize my go codebase?

I have a non trivial app (unix daemon) that talks to other processes, read/writes a database, talks to a web server, has internal state. In c++ i would write a bunch of classes (probably in subdirectories for the main subcomponents). Lets say that this is projd

Then at a higher level I have utility cli functions associated with the project. projcli1, projcli2.... I assume all the code associated with one project goes under one GOPATH

What If i was working on several unrelated projects. Do I still use one GOPATH or do I have one per project.

I tried to find sample code bases but the only large set is the packages repository, and that's a bunch of libraries - which is not really the same thing.

If those questions are too vague how about this. Is it correct that all the go files in the same directory have to be for the same package?

Another simple specific question. I found a nice implementation of an object pool. Its package says "pool" - fine. Where do I put its single file. In a subdir called 'pool', I would like to have a dir called utils (or something like that) seems like I cannot do it. I mean I cant have utils/pool and util/db (say) without having a tree of one file dirs

Your question is fairly vague, but you do ask a few answerable questions in it.

First, read http://golang.org/doc/code.html if you haven't already

You should only ever need one GOPATH; you can have several and switch between them, but I can't think of any use case for it.

All go files in a single directory must be for the same package, that is enforced by the compiler.

When organizing a large project in Go, it's all about choosing your packages and deciding what code goes in each package. A few useful tips:

  • package dependencies cannot be cyclic - if your theoretical layout would have two packages depending on each other, that will not work
  • subdirectories are entirely distinct packages - they have no special relationship to the package in their parent directory
  • each package should be independently useful - if you have to import package b in order to make use of the stuff in package a, your layout is confused
  • don't be scared of relatively large packages - it's weird at first to have lots and lots of go files in a single directory (where in other languages you'd be using subdirectories) but it doesn't actually cause too many problems

For large projects of the size you seem to be talking about, I find they usually end up in three or four packages: one or two implementing stand-alone core components that could theoretically be reused in other projects, one implementing the specific application functionality as a library, and one implementing the actual program (the daemon, or the user interface, or what-have-you). It always depends on the program of course.