I agree that not all linting is useful, but when I see certain outcome that is questionable, I would be investigating that a bit more if it was my code. For example: There is code that uses deprecated functionality, that could easily be changed to the newer version of that.
There are: - lots of ineffective assigns to be found (which means for some occasions extra work for nothing) - structs that could be made more memory efficient - type assertions that should be checked - unnecessary conversions - parts with unchecked errors - parts that have a high cognitive code complexity > for example "go/src/cmd/compile/internal/ssa/regalloc.go" func (s *regAllocState) regalloc(f *Func) who can read this? So yes, linters can be useful as well Op zaterdag 10 december 2022 om 10:30:00 UTC+1 schreef Brian Candler: > On Friday, 9 December 2022 at 19:09:34 UTC Ian Lance Taylor wrote: > >> 1) Linters are optional and opinionated, and it kind of matters which >> linter you mean. > > > And of course, go itself already comes with the grandaddy of all linters - > "go vet <https://pkg.go.dev/cmd/vet>". > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/cad99b3b-be54-4cfc-8699-edd42f01423cn%40googlegroups.com.
