Reviewed by Greg Wilson / 2022-04-06
Keywords: Quality, Static Analysis
I haven't gotten to the point of having a keyboard shortcut for
pip install black flake8 isort pydocstyle,
but linting tools are always the second thing I set up
after adding a README, a license, and a code of conduct.
I see most other developers doing the same thing these days,
and while I have no idea how to measure it,
I suspect these tools boost productivity more cost-effectively than unit testing.
They also found that 70% of developers use an existing pre-set configurations; "project fit" and "just the defaults" are the next most common strategies, while at the bottom end, automatically-generated configurations are used only 7% of the time. When asked what they find challenging, developers said that agreeing on rules as a team is the biggest problem (which may be why using the defaults is such a popular strategy). Creating and maintaining configurations came next; that surprised me a bit, but on the other hand, the team I'm on uses default settings so maintenance is not an issue. Of the other challenges, one is social (enforcing the rules), while others like false positives are targets for future technical work.
In a sense, papers like this do for open source what product managers do for commercial projects: gather, organize, and prioritize feedback about how the software helps or frustrates its users. I hope our lightning talks on April 27 will lead to more researchers helping more projects in this way.
A linter is a static analysis tool that warns software developers about possible code errors or violations to coding standards. By using such a tool, errors can be surfaced early in the development process when they are cheaper to fix. For a linter to be successful, it is important to understand the needs and challenges of developers when using a linter.