Contribution guidelines

Contributions to the project are always welcome! See HACKING for how to get started.

To make it easier for everybody here are some guidelines with some suggestions.

Reviews

  • When a PR got code review comments, please only push new revisions, do not alter history (no rebases, etc). This way it’s easier for the reviewer to check what changed since the last review and how comments got addressed. When doing the final merge, it’s fine to squash-merge though.

Error messages

  • All error messages are lower-cased, unless the first word is naturally upper-cased (acronym, etc)
  • Start the message with cannot Instead of: can’t, can not, could not, failed to, unable to, etc

Other

1 Like

Can you add guidelines on how to deal with cascading errors? That is

func func2() error {
    if _, err := func1(); err != nil {
        return fmt.Errorf("cannot ...: %s", err)
    }
    return nil
}

and somewhere else

if _, err := func2(); err != nil {
    fmt.Errorf("cannot ...: %s", err)
}

My go is rusty… but now that I rusted through it a bit, boy do I miss it :pensive:

Your example is actually fine. The thing to keep in mind, and we need to word that nicely somehow in the guidelines, is to report the action that is being attempted at the local site instead of the one above or the one below. For example, ("cannot open file %s: %v", err) is not very useful, because err will already inform that the file cannot be opened. Instead, the one at hand should say something along the lines of ("cannot read network configuration: %v", err), thus providing useful information while decorating it. If there’s no useful information to be provided, then just pass the error through and let the other layer do it if necessary.