revive VS golangci-lint

> Our coding standards require that functions have a fairly low cyclomatic complexity. The goal is to ensure that we never have a a function which is really hard to understand.

https://github.com/fzipp/gocyclo

> * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility and sensibility of each function signature very carefully. My thinking is the comment sort of describes "developer's intent" whereas the naming of everything in the signature should give you a strong indication of what the function really does.

https://github.com/mgechev/revive

> Now is this going to buy you good architecture for free, of course not.

It's not architecture to tell people to comment on their functions.

Also FTR, people confuse cyclomatic complexity for automagically making code confusing to the weirdest example I have ever had to deal with - a team had unilaterally decided that the 'else' keyword could never be used in code.

The Uber page does a pretty good job of summing it up. The only thing I'd add is that there has been a little bit of effort to reduce footguns since they've posted this article; as one example, the issue with accidentally capturing range for variables is now fixed in the language[1]. On top of having a built-in race detector since 1.1 and runtime concurrent map access detection since 1.6, Go is also adding more tools to make testing concurrent code easier, which should also help ensure potentially racy code is at least tested[2]. Accidentally capturing named return values is now caught by a popular linting tool[3]. There is also gVisor's checklocks analyzer, which, with the help of annotations, can catch many misuses of mutexes and data protected by mutexes[4]. (This would be a lot nicer as a language feature, but oh well.)

I don't know if I'd evangelize for adopting Go on the scale that Uber has: I think Go works best for shared-nothing architectures and gets gradually less compelling as you dig into more complex concurrency. That said, since Uber is an early adopter, there is a decent chance that what they have learned will help future organizations avoid repeating some of the same issues, via improvements to tooling and the language.

[1]: https://go.dev/blog/loopvar-preview

[2]: https://go.dev/blog/synctest

[3]: https://github.com/mgechev/revive/blob/HEAD/RULES_DESCRIPTIO...

[4]: https://pkg.go.dev/gvisor.dev/gvisor/tools/checklocks

The v1.3.4 of revive, the fast, configurable, extensible, flexible, and beautiful linter for Go, is available.

I would suggest checking out something like revive to improve the code. For instance you use an errors.New(fmt.Sprintf(... when you can just use fmt.Errorf(... to simplify it. I am not saying obey everything but there are some good lints included that can even catch bugs (for instance misusing errors.Is or errors.As or general equality).

Linting and static analysis: https://revive.run/

For people using this linter (like me) https://github.com/mgechev/revive

Been using https://github.com/mgechev/revive in all my projects.

The day after, I talked about the Hacktoberfest to Salvador (architect colleague and my technical/career unofficial mentor). He is known for contributing to revive a Golang linter. We decided that I could contribute by solving these 3 issues (2 new rules and add a docker image to the release). Since this moment, I have been coding every available hour I had. It felt so reviving to spend time coding on new projects, rewarding to solve issues for people actually using the tool. Here are all my contributions.

While golint may be deprecated it has been brought back as revive. You can also enable in golangci-lint.

The golangci-lint tool aggregates dozens of popular Go linters (like govet, staticcheck, errcheck, etc.) into a single, fast binary. It’s configurable, fast, and widely used in continuous integration (CI) pipelines.

The language is full of gotchas like that, you're expected to use the tooling to guardrail yourself, because having a proper type system or coherent syntax is "too complicated" (while learning dozens of patterns and weird tricks is apparently not).

go vet and this massive collection of linters bundled into a single binary are very popular: https://golangci-lint.run

linters will warn you of accidental shadowing, among many other things.

golangci-lint – for enforcing style and catching issues early

Consider using golangci-lint for comprehensive linting

I noticed this issue only after running a linter. Sometimes we’re not familiar with the tricky edge cases or conventions of a particular language. A convenient way to catch and fix such issues — including formatting, styling, and even some security problems — is to use linters. For example, you can use golangci-lint for Go, ESLint for JavaScript, and Pylint for Python. In fact, almost every widely used programming language has its own linter or code quality tool. Linters are especially helpful when generating code with AI — they help keep your code clean and safe, at least to some degree.

Static Analysis: Tools like golangci-lint or go-deadlock can spot some issues.

Linting is done using golangci-lint

Source Code Analysis: Most commercial static code analysis solutions, such as Sonar, support Go, but there are also open-source projects, such as golangci-lint.

One of the checkers in golangci-lint does this. I forget which one.

golangci-lint rolls up lot of linters and checkers into a single binary.

There is a config file too.

https://github.com/golangci/golangci-lint