"Out of the 20 people we interviewed, 14 people expressed the negative impacts of poorly presented output. ... Some of our participants felt, however, that false positives and large volumes of warnings would be less burdensome if the way the output is presented was more user-friendly and intuitive."

Sounds like you're in the majority.

I'm with you. I used FindBugs within Eclipse, just fine. But on my current project they (the company) tuned Sonar to be extreme. Every opinion is a Major bug at least and breaks the build. I like to have lines like this:

Something s = function(....); return s;

This allows me to put a break point if I need one in the future. Unfortunately Sonar is configured to say this is a Major bug. It breaks the build until I have "return function(...)." Every damn time! Now I use (assert s != null);

If a company can come up with a default configuration that Jenkins or Bamboo can pull, great! I love it. Until then I literally have to push to SVN and wait for the Sonar nag email.

I found that specific Sonar issue to be bogus. In addition to breakpoints, sometimes the 's' has is meaningful name that ties the function call with the return value.

Guessing you're referring to the infamous Python PEP-8 limitation. Most linters let you trivially change this line length in a way which either affects the linter permanently, or on a per-project basis.

For example, you can get very fine grained control over pylint by asking it to generate a config file, and reading through it (it's remarkably well commented).

You still have to go through the config and enable/disable things for your project. That's the biggest barrier; the lack of good default configs to use for flake8 and pylint. If Google or Microsoft or someone else supplied one, I'd just take it and drop it into every project. One less headache to worry about.

That's a remarkably low barrier to entry. Not to mention that the coding standard they are enforcing is based on the official language coding standards - that makes them very reasonable defaults.

Yep it is and yet the coworkers don't want to do anything about setting up the infrastructure for static analysis or code checking of any kind. It's an attitude I've encountered at many other companies which is unfortunate.

I think it boils down to being timid and not wanting to impose one standard on others which reduces the importance of coding standards to tabs vs spaces -_-'

The effort:reward ratio is still out of whack here, though. Linters are relatively limited in usefulness at the best of times (compared to tests, for instance).

Linters that can't rank rule violations sensibly, have bad defaults and opinionated stylistic rules quickly become more trouble than they're worth.

If somebody comes out with a better linter, though, that isn't verbose and just catches truly problematic code consistently without needing a ton of customization, I'll use that for sure.

what tools? afaik, none of the tools mentioned in the article warn on whitespace or line length. FindBugs certainly does not.

I've used Klocwork. It will tell you all kinds of nitpicking stuff, but you can get it out of your face very easily, and just look at the stuff that you think is important.

But if you're in virmundi's situation, that's more a people problem than a technical one, and no tool will save you there.

grep -v

if you have to make a dozen of grep to exclude trivial results, it might be a hint there's something wrong with the pertinence of your output or the customizability of your tool

I found most tools very verbose but I've yet to use a tool where it doesn't have the ability to exclude certain warnings.

From another perspective, hacking often involves making broken things work better.

From yet another perspective: don't use broken tools.

I keep forgetting this one: don't offer help to complainers.

If the help constitutes telling people about this wonderful new tool you've just discovered called grep, perhaps that's for the best.