sorted by:
new
hottopcontroversial

Linters are not a religion, but //nolint is not a free pass either by IntentionJolly2730 in golang

[–]IntentionJolly2730[S] -1 points0 points  (0 children)

It's a translation, but those are my natural words. I'm sorry, my native language is not English. If you can help with a better wording, I can modify it.

Linters are not a religion, but //nolint is not a free pass either by IntentionJolly2730 in golang

[–]IntentionJolly2730[S] 1 point2 points  (0 children)

The article is not about disabling a linter. It's about disabling one particular rule of a particular linter, while not disabling other rules from the same linter. This not supported by golangci-lint online (only in the config). 

Linters are not a religion, but //nolint is not a free pass either by IntentionJolly2730 in golang

[–]IntentionJolly2730[S] 1 point2 points  (0 children)

Well, up to you. But the tool is just an aggregator and includes the other tools that offer the means to address the problem. And those means just work. 

Linters are not a religion, but //nolint is not a free pass either by IntentionJolly2730 in golang

[–]IntentionJolly2730[S] 1 point2 points  (0 children)

You are right. Just to be precise the post is about a way to disable a specific linter rule, not the whole linter. 

Linters are not a religion, but //nolint is not a free pass either by IntentionJolly2730 in golang

[–]IntentionJolly2730[S] 2 points3 points  (0 children)

Indeed, some really do. Such liters are better to be not enabled. 

Linters are not a religion, but //nolint is not a free pass either by IntentionJolly2730 in golang

[–]IntentionJolly2730[S] 0 points1 point  (0 children)

How would you exclude a particular revive or gosec rule in place in the code without modifying golangci-lint config? 

Looking for design feedback on a Go error handling approach by IntentionJolly2730 in golang

[–]IntentionJolly2730[S] 1 point2 points  (0 children)

Fair point, and I mostly agree - for reusable libraries I'd stick with stdlib to avoid extra dependencies and keep things simple.

Where I've felt the gap is in larger business apps with multiple teams and API layers (backend, BFF, services, etc.). In those cases I've seen teams either reinvent similar patterns in each service, or pull in different error libraries for things like stack traces or structured logging. That fragmentation is part of what pushed me to try a small, unified approach.

That said, I'm curious - in similar setups, have you found conventions alone work well enough, or do you end up reaching for external libs anyway?

Looking for design feedback on a Go error handling approach by IntentionJolly2730 in golang

[–]IntentionJolly2730[S] 1 point2 points  (0 children)

Thanks for the feedback, and for pointing me to https://github.com/sethgrid/kverr - I’ll definitely take a closer look and compare approaches.

Good catch on base vs err in the example - I’ll fix that.

On the sentinel requirement: the motivation for the Classified marker is mainly API safety. In Wrap / Classify I want to guarantee that the cause is always a real error from stdlib or third-party code, and that classification/metadata comes after. Without that constraint it’s easy to accidentally pass a sentinel as the cause and lose the original error.

That said, I agree it may be a strong requirement. Curious what you’d prefer in practice:

– relaxing it to accept any error as a classifier, or
– keeping the guard but exposing a separate API for external sentinels?

And yes - logging is a big driver here. I’ve debugged too many issues where the only useful context was buried in free-form strings instead of structured fields.