These guidelines for writing Go code are WIP
This document covers common coding styles and guidelines for all ForgeRock products.
Within the FRaaS codebases we are not currently adding licence headers to individual source files. This practice diverges from the standard practice of doing so across other projects.
In addition to good documentation, having a consistent approach to organising code across directories and within a given source file makes it easier for engineers to move between projects and get up to speed quickly.
Where possible, agreed standards relating to source files should be enforced by linting during continuous integration. The linting rules currently in use by the FRaaS team are:
linters: # inverted configuration with `enable-all` and `disable` is not scalable during updates of golangci-lint disable-all: true enable: - deadcode - errcheck - gofmt - goimports - gosimple - govet - ineffassign - structcheck - typecheck - unused - varcheck run: tests: true
errors.Wrapto add context to the returned error.
github.com/pkg/errorspackage instead of
errors, and user
errors.WithStack(err)wherever an error is produced or returned from an external package.
WithStackproduces a stack trace pointing to the line of code which produced the error, which also prevents us from having to add our own custom error message so that we can correlate the error message to the line of code which produced it.This can also be done wherever there's an
In addition to the points raised above, we should endeavour to write idiomatic Go. Guidance for what these idioms are and how to follow them can be found in: