Hacker News Reader

Comment by fivea | Hacker News Reader

> The CI check is the important one: It's what ensures that bad formatting doesn't make it into master.

I'd say that running linters in precommit hooks is the ideal use case, as linters do not belong in CICD pipelines (i.e., it would make absolutely no sense to block a release just because a whitespace didn't matched an arbitrary rule) and linting stuff before committing also eliminates iterations in code reviews to handle inane stuff like where to break a line or how many spaces come before and after a bracket.

View on HN

That’s a pretty reductive attitude towards linters. If writing Go (for example), linters will tell you if you have ineffective assignments, or have neglected to check an error value - both things that may well block releases.

While one could argue these are the job of the compiler, they are not today, and so linting during CI is not only appropriate, but practically required.

> While one could argue these are the job of the compiler, they are not today, and so linting during CI is not only appropriate, but practically required.

I disagree. Stylistic choices should not block a pipeline. It's impossible to argue in favour of blocking a release just because there's a whitespace in a place where it makes some random developer frown. The robustness principle also applies here.

And no, build/critical errors are not the same as stylistic/linting errors.

Whether you check errors is a correctness issue, not a stylistic one.

The fact that Go requires a linter to ensure errors are properly handled is a whole other topic

I don’t disagree there.

IMO linters definitely belong into the CI/CD pipeline. I do block a release if there are whitespace issues - it's trivial for the developer to fix, and part of basic code hygiene standards that we enforce in every repository.

And if there is an emergency hotfix that needs to go out as soon as possible, we do have processes in place to bypass the CI/CD checks.

Reply on news.ycombinator.com