A linter analyzes source code to detect errors or improvements. The golint linter is available on https://github.com/golang/lint for installation (it doesn't come bundled with the compiler). It is very easy to use and is integrated some IDEs to be run when you save a source code file (Atom or Sublime Text, for example). Do you remember the implicit/explicit code that we run when talking about variables? Let's lint it:

//Explicitly declaring a "string" variable 
var explicit string = "Hello, I'm a explicitly declared variable" 
    
//Implicitly declaring a "string". 
Type inferred inferred := ", I'm an inferred variable " 

$ golint main.go

The main.go:10:21: command should omit the type string from the declaration of the explicitString variable; it will be inferred from the right-hand side.

It is telling us that Go compiler will actually infer this type of a variable from the code and you don't need to declare its type. What about the Train type on the interface section?

Type Train struct { 
    TrainWidth int 
} 

$ golint main.go

The main.go:5:6: type exported Train type should have a comment or remain not exported.

In this case, it's pointing us that a public type such as Train type must be commented so that users can read the generated documentation to know its behavior.

The gofmt tool comes bundled with the compiler that already has access to it. Its purpose is to provide a set of indentation, formatting, spacing and few other rules to achieve good-looking Go code. For example, let's take the code of Hello World and make it a bit weirder by inserting spaces everywhere:

package main 

func  main(){ 
    println("Hello World!") 
} 

$ gofmt main.go 
package main 
 
func main() { 
        println("Hello World!") 
} 

The gofmt command prints it correctly again. What is more, we can use the -w flag to overwrite the original file:

$ gofmt -w main.go

And now we'll have our file properly corrected.

Go documentation is pretty extended and verbose. You can find detailed information about any topic you want to achieve. The godoc tool also helps you access this documentation directly from the command line. For example, we can query the package encoding/json:

$godoc cmd/encoding/json
[...]
FUNCTIONS
func Compact(dst *bytes.Buffer, src []byte) error
Compact appends to dst the JSON-encoded src with insignificant space
characters elided.
func HTMLEscape(dst *bytes.Buffer, src []byte)
[...]

You can also use grep, a bash utility for Linux and Mac, to find specific information about some functionality. For example, we'll use grep to look for text that mentions anything about parsing JSON files:

$ godoc cmd/encoding/json | grep parse

The Unmarshal command parses the JSON encoded data and stores the result in the object being parsed.

One of the things that the golint command warns about is to use the beginning of a comment with the same name of the function it describes. This way, if you don't remember the name of the function that parses JSON, you can use godoc with grep and search for parse so the beginning of the line will always be the function name like in the example preceding the Unmarshal command.

The goimport tool is a must have in Go. Sometimes you remember your packages so well that you don't need to search much to remember their API but it's more difficult to remember the project they belong to when doing the import. The goimport command helps you by searching your $GOPATH for occurrences of a package that you could be using to provide you with the project import line automatically. This is very useful if you configure your IDE to run goimport on save so that all used packages in the source file are imported automatically if you used them. It also works the other way around--if you delete the function you were using from a package and the package isn't being used anymore, it will remove the import line.