惯用的Go代码组织

Question

Note: I've seen other questions related to this topic but none that address the issue at hand.

I'm struggling to organize my Go code. I'm writing a daemon and I would like to split the code logically between files.

Say I have 3 files, main.go:

package main

func main() {
    GlobalFunc()

    commonFunc()

    var svr server.Server
    server.OtherFunc()
}

server.go:

package main

type Server struct {
    name string
    ip string
}

func GlobalFunc() {

}

func (s *Server) OtherFunc() {
    commonFunc()
}

and common.go:

package main

func commonFunc() {

}

I would like to be able to call GlobalFunc() as server.GlobalFunc() to show it's part of the "server module". That doesn't seem possible with the above example.

I could make a subdir server, put server.go in there, and change it to package server. The problem here is that I can't seem to shared common.go between the main and the server package. I understand why, it doesn't seem like a good idea either.

So I am missing something simple here and making this more complicated?

Thanks!

Answer 1

I think it's fair assumption you'd like to use some common methods across your projects. The same way you separate the server, you should then separate the package with the common methods. Although it's probably better to think and organise it in some logical way, rather than calling the package tools, misc etc.

I tend to split things into packages, so they can be used in other places, while the main package would be simply flag parsing and calling the library methods, for example server.Run(). Other people like to put everything into the main project, which might be all right if you think people would use your project as a command line tool, rather than a package.

I would consider:

deamon/
    main.go
    server/server.go
    somelib/somelib.go -- to be included from main and server

If you would like your project to be used mainly as a package, but still include some command line utility, you might consider:

deamon/
   deamon.go -- package deamon
   deamond/
       main.go -- you may include the top level package as anyone else

We need to remember that in Go you include your packages with an absolute path, so you can keep your "common" stuff anywhere in the project, or if you decide is useful by itself, just release a separate, standalone project.