Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Go Style Guide

This page explains preferences in regard to the style of Go code written for the DAOS (and other related) project(s).

It's not necessary to rewrite a style guide from scratch given there are plenty of good ones already in existence, therefore please view this as a supplement to Effective Go and Go Code Review Comments .

...

Whilst the recommendations given in the above links give comprehensive guidance, exceptions and points of note specific to this organisation are covered below.

Anchor
linters
linters
Linters

Run goimports, a superset of `gofmt` which additionally adds (and removes) import lines as necessary. gofmt automatically fixes the majority of mechanical style issues. Almost all Go code in the wild uses `gofmt`. The rest of this document addresses non-mechanical style points. use-linters give some explanation of the importance of running code through linters before committing.

Anchor
function-naming
function-naming
Function Naming

Short, C-like function names are preferred, in mixed-caps . Attempt to keep naming to 3 words maximum and less than 12 characters.

Anchor
comment-sentences
comment-sentences
Comment Sentences

See commentary. Comments documenting declarations should be full sentences, even if that seems a little redundant. This approach makes them format well when extracted into godoc documentation. Comments should begin with the name of the thing being described and end in a period:

...

and so on. Note that there are other symbols except a period that can be a valid end of sentence (at least !, ?). Apart from that there are many tools that use comments to mark types and methods (like easyjson:json and golint's MATCH). It makes this rule hard to formalize.

Anchor
comment-usage
comment-usage
Comment Usage

Comments should be used to describe the intent of code when it is not obvious. commentary