lint

The worst thing about go, it's its dev community. Anyone who claims otherwise probably hasn't read any of the GitHub discussions (things like this https://github.com/golang/lint/issues/65 are pretty common; when users are being told they don't understand how amazing Go is.)

Actually, the mistake is mine, I meant to write golint (but too late to edit). I have no issue with gofmt. As for golint, https://github.com/golang/lint/pull/100 is the kind of thing I'm thinking about.

The best example of this for me is the initialism style rule: > Words in names that are initialisms or acronyms (e.g. "URL" or "NATO") have a consistent case. For example, "URL" should appear as "URL" or "url" (as in "urlPony", or "URLPony"), never as "Url". Here's an example: ServeHTTP not ServeHttp. > This rule also applies to "ID" when it is short for "identifier," so write "appID" instead of "appId". > Code generated by the protocol buffer compiler is exempt from this rule. Human-written code is held to a higher standard than machine-written code. To enforce this in the linter they literally define a list of initialisms[1]. [1]: https://github.com/golang/go/wiki/CodeReviewComments#initial... [2]: https://github.com/golang/lint/blob/master/lint.go#L695

GitHub has the meta tag on some, but not all of the pages where 'go get' expects to find the tag. An example of a page without the tag is https://github.com/golang/lint/golint?go-get=1.

It's interesting that GitHub added the meta tag given that 'go get' and similar tools like godoc.org don't look for the tag on GitHub. These tools have knowledge about GitHub baked in. Also, GitHub does not include the meta tag on all pages where 'go get' would expect to find the meta tag. For example, the tag is not on the page https://github.com/golang/lint/golint?go-get=1.

> While Go has very deliberately not implemented class hierarchies, a quick perusal of Go's net and os packages should indicate that sometimes error hierarchies are useful. I just want to point out - I would hesitate from drawing too many conclusions from "net" and "os" (the latter in particular). Not only is "os" some of the oldest Go code, but it is also designed to wrap conveniently around external interfaces that follow very different idioms. Another example would be the constant declarations[0], which use ALL_CAPS - this is actually not idiomatic in Go, but it is used here (a) because it was done very early on, and (b) because it more closely matches the C libraries it interfaces with[1]. I need to take a closer look at this errors package before drawing an opinion about the rest of it, but this sentence caught my attention. [0] http

`go vet` (checks correctness) and golint (https://github.com/golang/lint) are also extremely useful. As a whole the toolchain makes working with Go code very convenient.