The goal of this document is to describe how Beeper writes Go code. This includes code style, library choices, and other important guidelines.

Style

The following style guidelines are meant to supplement existing style guides and to add additional emphasis on certain rules that are especially important for Beeper and elaborate on some rules that only apply to us.

Base style guides:

General

Variables

Control Flow

A corollary is that reading the left-aligned code should describe the happy-path.

```go
// do this
func stuff() error {
    err := couldError()
    if err != nil {
        return err
    }
    doThing()
    doOtherThing()
    doAnotherThing()
    return nil
}

// not this
func stuff(thing bool) error {
    err := couldError()
    if err == nil {
        doThing()
        doOtherThing()
        doAnotherThing()
    }
    return err
}
```

- **Exception:** if there are multiple different conditions, and all of the blocks are short (a few lines), an `if` chain can be nicer. This is especially nice if all the conditions would need a `return` normally.
    
    ```go
    package main
    
    func erroringThing() (err error) {
      if err = stuff1(); err != nil {
        err = fmt.Errorf("failed to do thing #1: %w", err)
      } else if err = stuff2(); err != nil {
        err = fmt.Errorf("failed to do thing #2: %w", err)
      } else {
        fmt.Println("Success")
      }
      // implicitly return err
      return
    }
    
    ```

Pre-Commit Hooks

The following pre-commit configuration should be used (replace YOURSERV with the name of your module). Run pre-commit autoupgrade to get the latest versions.

Databases