Follow industry, team, and language conventions

Concepts, variables, and function names all just make sense when they follow conventions. Ask yourself, if you are working on a system about cars, what would you expect a variable called flower to be?

Coding style is arguably something that Go got right. For many years, I was part of the bracket placement and the tab versus spaces wars, but when switching to Go, all of that changed. There is a fixed, documented, and easily reproducible style—run gofmt, problem solved. There are still some places where you can hurt yourself. Coming from a language with unchecked exceptions, you might be tempted to use Go's panic() phrase; while possible, it is one of several conventions explicitly discouraged in the official Code Review Comments wiki (https://github.com/golang/go/wiki/CodeReviewComments).

Team conventions are a little bit harder to define, and perhaps sometimes to follow. Should a variable of the channel type be called result, resultCh, or resultChan? I have seen, and probably written, all three.

How about error logging? Some teams like to log errors at the point at which they are triggered, and others prefer to do so at the top of the call stack. I have a preference, as I am sure you do, but I have yet to see an overwhelmingly compelling argument for either.