|
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. |