magnetico Design Specification

Go Programming Guidelines

These are not meant to be some generic programming advice, but are specific to magnetico.

• Code must be formatted using gofmt.
• Code must be statically analysed:
  • Code must pass go vet.
  • Code must pass staticcheck.
  • Appropriate unit tests must be written.
    • Whenever an assumption is made about a 3^rd party code, a unit test which tests that assumption must be written.
  • Write integration tests whenever possible.
• Prefer blocking callbacks over channels and non-blocking (asynchronous) callbacks:

  • A blocking callback -if desired- can easily be converted into a non-blocking (async) callback by starting a goroutine in the callback (unless some data is returned from the blocking callback).

    func myBlockingCallbackFunc(data struct{}) {
        go myAsyncCallbackFunc(data)
    }

  • A blocking callback -if desired- can easily write to a channel.

    func myCallbackFunc(data struct{}) {
        myChannel <- data
        // ...plus, we have the flexibility to take an alternative action
        // if the channel is full!
    }

  • Go channels are bad and you should feel bad

• Prefer as little goroutines as possible.
  • Don't abuse it just because you could.
• Put limits on things that can grow indefinitely, such as on:
  • the number of torrents whose metadata we are fetching concurrently
  • the number of DHT nodes we have as our neighbour
  • etc.

Source Tree

• magnetico's source tree consists of three main components
  1. pkg/persistence that abstracts access to database, and is shared between magneticod and magneticow.
  2. cmd/magneticod for magneticod specific code.
  3. cmd/magneticow for magneticow specific code.