5 ms·

Mainly because most of the tool reports freely mix critical issues with stuff that is just opinionated bullshit (e.g. 80 character length lines). When the outp

Mainly because most of the tool reports freely mix critical issues with stuff that is just opinionated bullshit (e.g. 80 character length lines). When the output is as long as your arm and you have pick through it with a fine toothcomb to find the things that matter (and even they aren't necessarily causes of bugs), the whole idea becomes substantially less appealing.

yeahdude 11y ago
grep -v
- rjaco31 11y ago
  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
  - yeahdude 11y ago
    From another perspective, hacking often involves making broken things work better.
    - crdoconnor 11y ago
      From yet another perspective: don't use broken tools.
      - yeahdude 11y ago
        I keep forgetting this one: don't offer help to complainers.
        crdoconnor 11y ago
        If the help constitutes telling people about this wonderful new tool you've just discovered called grep, perhaps that's for the best.
  - nadams 11y ago
    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.
Hello71 11y ago
what tools? afaik, none of the tools mentioned in the article warn on whitespace or line length. FindBugs certainly does not.
SloopJon 11y ago
"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.
falcolas 11y ago
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).
- omouse 11y ago
  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.
  - falcolas 11y ago
    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.
    - omouse 11y ago
      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 -_-'
- crdoconnor 11y ago
  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.
virmundi 11y ago
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.
- karmakaze 11y ago
  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.
AnimalMuppet 11y ago
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.

yeahdude 11y ago

grep -v

rjaco31 11y ago
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
- yeahdude 11y ago
  From another perspective, hacking often involves making broken things work better.
  - crdoconnor 11y ago
    From yet another perspective: don't use broken tools.
    - yeahdude 11y ago
      I keep forgetting this one: don't offer help to complainers.
      - crdoconnor 11y ago
        If the help constitutes telling people about this wonderful new tool you've just discovered called grep, perhaps that's for the best.
- nadams 11y ago
  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.

Hello71 11y ago

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

SloopJon 11y ago

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

falcolas 11y ago

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

omouse 11y ago
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.
- falcolas 11y ago
  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.
  - omouse 11y ago
    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 -_-'
crdoconnor 11y ago
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.

virmundi 11y ago

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.

karmakaze 11y ago
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.

AnimalMuppet 11y ago

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.