Go, Hound, and Code Review Comments

Go has a vibrant ecosystem of tools for writing better code, from the standard go fmt command for automatically formatting your code and go vet for detecting incorrect constructs not caught by the compilers, to community projects like safesql for finding SQL injection points and many, many more.

One thing most of these tools have in common is that they have binary outcomes: code is correctly formatted after running go fmt; code which is flagged by go vet is incorrect. This means they can be run automatically. Some, like go fmt, after saving in an editor, others as a part of the build or CI process.

But not all tools have such strong guarantees.

Golint

Golint is a linter for Go source code. Where other tools are concerned with formatting or correctness, Golint is concerned with style.

Golint automates many of the suggestions found in Effective Go and the CodeReviewComments wiki page.

For example, if you run Golint against the following code:

package request

func RequestFromJSON(data []byte) (Request, error) {
  // ...
}

It will note that:

func name will be used as request.RequestFromJSON by other packages, and that stutters; consider calling this FromJSON.

It will also check that exported methods and types have properly formatted comments, receiver names are consistent across methods definitions, initialisms like JSON and HTTP are capitalized for consistency with other packages, and much more.

Golint is a valuable tool for helping to maintain a consistent style both within a package, and with the larger Go ecosystem.

It’s good to keep in mind, though, that Golint is not perfect:

The suggestions made by golint are exactly that: suggestions. Golint is not perfect, and has both false positives and false negatives. this tool is not, and will never be, trustworthy enough for its suggestions to be enforced automatically, for example as part of a build process.

This makes it a bit awkward to use: it can’t be run on CI but most developers won’t want it to run on save, either. Also for projects that accept changes from a large number of developers, particulary open source projects, it’s problematic to rely on a particular local development environment.

Enter Hound

What does Hound have to do with all this?

We recently added support for Go and Golint with a service written in Go!

Hound is a great way to lint your Go code, because that’s what it’s built for: it’s continuous integration for style!

Hound integrates with your existing GitHub Pull Request workflow, adding Golint suggestions as comments on the files in a PR.

This turns out to be a great place for style suggestions to go:

• It doesn’t rely on any particular local setup.
• It’s where you would discuss style if Golint didn’t exist.
• If you disagree, you can talk about it inline.
• If you update the PR to adopt a suggestion, the comment will be marked as outdated.

We think Hound is the best way to add style-checking to your workflow. And since it’s free for open source projects, it couldn’t be easier to get started.

Let us know what you think!