Notes on Go style about eliasdb HOT 2 CLOSED

Hi Chris,

thanks for your comment.

To point 1)

The reason the Github repository looks like this is that it includes documentation, design documents and tutorials. The actual code repository for embedding of EliasDB doesn't live on Github at all but rather on my own server which is reachable under devt.de. Having an own build server gives me the ability to have regular overnight builds and unit tests.

What you see on Github is a complete Go project structure. People doing a checkout from Github will receive everything while people who do a "go get" will only receive the source code.

I describe these two methods under "Building EliasDB" but maybe it is not clear enough? I do know that this approach is not what other projects do but it does work for me so far and I don't see any drawback in the moment.

I would say the main artifact of EliasDB is the single executable which lives directly under devt.de/eliasdb. The main file gives you a good starting point of how everything fits together.

Architecturally, the closest thing to a top-level API in EliasDB is I think the graph.Manager class. However, there is nothing stopping you from just using the hash and storage API and basically use EliasDB as a key-value store. I am in two minds here, I think I favor slightly the current organisation where you have separate layers each with defined interfaces and the graph package is just one of them.

In "Organizing Go code" (https://blog.golang.org/organizing-go-code) it is said that there is "no hard and fast rule" for package size. I am not a big fan of "fat" packages as it makes reading code harder, in my opinion. The current packages are self contained modules and the unit test runtime for most of them is reasonable - if you change any code you can run the package unit tests frequently without getting annoyed.

To point 2)

The code does only use fully qualified imports. The code "lives" indeed under devt.de and not github.com.

To point 3)

Stuttering is indeed bad practice and I do agree graphstorage.Graphstorage is a stutter. I'll change it.

To avoid stuttering I run golint as part of my build process. In fact my build breaks if I have any golint or go vet messages. In case of graphstorage.Graphstorage the tools seem to accept it.

from eliasdb.

I've changed now graphstorage.GraphStorage to graphstorage.Storage. I also adjusted the "Building EliasDB" section a bit and explicitly say now when to use which approach for code retrieval.

from eliasdb.