This seems to equate linters with other kinds of tools, and I think that's mistaken.
Linters attempt to look for "less than best practices". When you update a linter, you often also need to update code for the new style rules (unless you just don't care about the results). Those reports can be helpful, because those style rules can also warn about real problems like security vulnerabilities. But most are minor issues, so it may make sense to delay them.
I would generally prioritize outputs of tools that are designed to find serious problems (like security vulnerabilities), and then update things like linters when I can (but consider those lower priority). We should be unsurprised to find developers prioritizing some kinds of reports over others.
I think this definition is outdated - linters find real bugs now. The boundaries between linters, static analyzers, and security tools in real life are basically nonexistent, it's entirely tool by tool. Also, autoformatters should style code, not linters. Used to be that linters told you about code style issues, and many still do, but ppl should turn all rules off and use autoformatters instead. Much easier/better.
I disagree that the definition is "outdated". Yes, linters find real bugs, I never said they couldn't. But tools typically called "linters" routinely also report things that aren't serious defects, while other tools that focus on specific issues (e.g., security vulnerabilities) tend to find those issues. A "static analyzer" is anything that analyzes code without running it, so linters and Static Application Security Testing (SAST) tools are both kinds of static analysis tools. Linters and SAST tools (for example) tend to focus on different kinds of rules. Under the hood they may use the same underlying technology, but they're applying them differently, so it makes sense to have different words for them.
You might find real bugs with these linting rules, sure. But if I want to prioritize finding and fixing security defects, I'll prioritize fixing the security defects found by a tool designed to find the most likely kinds of security defects (e.g., look for XSS, SQL injection, etc.). Not these rules. You can have code that violates many ESLint rules and still works correctly for end-users.
That doesn't mean linters are useless. Quite the contrary, I think linters are really helpful & I strongly encourage their use. Fixing issues found by linters can not only fix real bugs, but they can sometimes encourage creation of simpler code that is easier to analyze by both humans and machines. But I wouldn't prioritize updating a linter over updating other tools and fixes. Yes, update linters, but when you have limited resources, that's not where you spend your first hour.
I think there's a lot of legitimate debate about autoformatters, that's a different topic.
Comments
This seems to equate linters with other kinds of tools, and I think that's mistaken.
Linters attempt to look for "less than best practices". When you update a linter, you often also need to update code for the new style rules (unless you just don't care about the results). Those reports can be helpful, because those style rules can also warn about real problems like security vulnerabilities. But most are minor issues, so it may make sense to delay them.
I would generally prioritize outputs of tools that are designed to find serious problems (like security vulnerabilities), and then update things like linters when I can (but consider those lower priority). We should be unsurprised to find developers prioritizing some kinds of reports over others.
I think this definition is outdated - linters find real bugs now. The boundaries between linters, static analyzers, and security tools in real life are basically nonexistent, it's entirely tool by tool. Also, autoformatters should style code, not linters. Used to be that linters told you about code style issues, and many still do, but ppl should turn all rules off and use autoformatters instead. Much easier/better.
I disagree that the definition is "outdated". Yes, linters find real bugs, I never said they couldn't. But tools typically called "linters" routinely also report things that aren't serious defects, while other tools that focus on specific issues (e.g., security vulnerabilities) tend to find those issues. A "static analyzer" is anything that analyzes code without running it, so linters and Static Application Security Testing (SAST) tools are both kinds of static analysis tools. Linters and SAST tools (for example) tend to focus on different kinds of rules. Under the hood they may use the same underlying technology, but they're applying them differently, so it makes sense to have different words for them.
So let's look at ESLint's list of rules: https://eslint.org/docs/latest/rules/ Here are some examples:
* getter-return: Enforce `return` statements in getters
* no-constant-condition: Disallow constant expressions in conditions
* no-fallthrough: Disallow fallthrough of `case` statements
* no-irregular-whitespace: Disallow irregular whitespace
You might find real bugs with these linting rules, sure. But if I want to prioritize finding and fixing security defects, I'll prioritize fixing the security defects found by a tool designed to find the most likely kinds of security defects (e.g., look for XSS, SQL injection, etc.). Not these rules. You can have code that violates many ESLint rules and still works correctly for end-users.
That doesn't mean linters are useless. Quite the contrary, I think linters are really helpful & I strongly encourage their use. Fixing issues found by linters can not only fix real bugs, but they can sometimes encourage creation of simpler code that is easier to analyze by both humans and machines. But I wouldn't prioritize updating a linter over updating other tools and fixes. Yes, update linters, but when you have limited resources, that's not where you spend your first hour.
I think there's a lot of legitimate debate about autoformatters, that's a different topic.