[overlordalex]

Nice article - one nitpick is that I absolutely do /not/ make the checks mandatory as part of the build process. Rather there are some "opinionated" checks that are run when code is pushed for review (which can be skipped), and then strong checks run as the first step in the CI/CD pipelines. This means that the tools stay out of the way when developing and running locally, but still enforce standards where required. This leads to fewer developers disabling or @ignore-ing rules to test things locally and then forgetting to remove them.

This article also reminds me of a talk I saw from Neal Ford about architectural fitness functions: the idea being that if there is an architectural pattern that should be followed then the best place to put it is in an automated step as part of your CI/CD. I thought it was interesting to take the concept normally limited to linters and apply it to a more abstract principle

[eru]

I agree. Curiously, the authors of the Go language disagree.

[SAI_Peregrinus]

I think it depends on the check. Some checks are better enforced strictly in an automated fashion. Style rules are a good example: they make no performance difference, lead to bikeshedding, and are pretty much arbitrary. Other checks should be made automatically but not strictly enforced. EG you might want to require all C casts to have a comment describing why it's safe. That can be a good linter warning, and linters tend to have codes that can be added in comments to suppress the warning. So the linter warning can make code review easier, but shouldn't necessarily fail the build.

[eru]

Go fails the build, when you have an unused variable.