Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

What's the right way to organize my Go project code?

I’ve only worked with Go code a couple of times (the Go wrapper of the DataStax C++ driver for Apache Cassandra is one of them). But my familiarity with the rules and practices in the Go land is very limited. So when I looked to start a toy project I have found myself asking again: what’s the right way to organize my Go project code?

I have found very little online. The first, is Ben Johnson’s Structuring Applications in Go:

I used to place my main.go file in the root of my project so that when someone runs “go get” then my application would be automagically installed. However, combining the main.go file and my application logic in the same package has two consequences:

  1. It makes my application unusable as a library.
  2. I can only have one application binary.

The best way I’ve found to fix this is to simply use a “cmd” directory in my project where each of its subdirectories is an application binary.

There are some additional hints in the article about Go project code org, and some

I had very high hopes that I’ll find the final answer in David Crawshaw’s slides Organizing Go code. The slides are really interesting, but unfortunately they don’t provide the answer I was looking for.

Finally, I’ve run into Dave Cheney’s Five suggestions for setting up a Go projec. This article provides suggestions for the following types of projects:

  1. a single package
  2. multiple packages
  3. a command
  4. a command and a package
  5. multiple commands and multiple packages

All I read in this post makes sense to me. So until I hear other recommendations, this will be what I’ll be using.

No Soup for you

Don't be the product, buy the product!

YES, I want to SOUP ●UP for ...