Thoughts

mental health break ,./'"**^^$_---
I think for me to be willing to use any linter, you would have to be able to disable specific errors on a per-line basis *in a config file*.
It seems to me that should be table-stakes. But the feature-parity (last I checked) was that you could disable an error entirely in a config file (e.g. I could tell the linter not to check "too-many-arguments to function" period) or you could disable it for a line with a comment (e.g. "// eslint:disable too-many-arguments" on the line with the function declaration). I think it should go without saying why both of those are unacceptable to me. But apparently I need to spell it out. I would be okay with the linter letting me know "hey you're using a lot of arguments here, that's an anti-pattern." I would then think about how I could refactor that section of code, and possibly come up with a better solution. But sometimes I wouldn't; sometimes I'd decide passing a lot of arguments is the idiomatic solution. It doesn't make sense for me to disable the error globally, since in this case there would just be one exception to the rule. And I don't want to disable it in-line because I don't want my linter config to be mixed in with my code. I'm here to write beautiful code and adding a linter-specific config comment that is unintelligible to anyone who hasn't read the linter docs or written a linter doesn't help my code readability. (What does `AbcSize` mean in `rubocop:disable Metrics/AbcSize`? Obviously Assignment, branch, complexity size. How do you calculate that? (It's not addition.) Rubocop delegates explaining that to a page that only talks about C++. Apparently "lint rules should be understandable by the person writing the code" is not a goal linters try to achieve.)
Link 11:58 a.m. Jul 21, 2022 UTC-4