Overview

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

We intend to follow the official coding style and idioms used in the standard library, therefore please view this as a supplement to Effective Go and Go Code Review Comments .

**Please discuss changes before editing this page**, even _minor_ ones. Many people have opinions and this is not the place for edit wars.

Points of note

Clarifications of rules that are already covered in the official style guide.

• line-width
• linters
• function-naming
• comment-sentences
• comment-usage
• use-mocks

Line Width

Avoid very long lines but don't enforce a 80-column limit, not having a line limit simplifies the use of goimports and gorename. See line-length.

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.

Naming

Keep function and variable names as short as possible, C-like function names are preferred where possible in mixed-caps . Attempt to keep function and variable names to less than 20 characters and less than 5 words.

Comment Sentences

See comment-sentences. 

Comment Usage

Use of comments is encouraged, comments should be used to describe the intent of code when it is not obvious. See commentary.

Using Mocks In Tests

Use of mocking when writing tests is encouraged, see here for a discussion of the use of mocking in go. GoMock is the recommended mocking framework.

Exceptions

Deviations from rules that are already covered in the official style guide.

Currently none.