cl : Command line warning D9040: ignoring option '/analyze'; Code Analysis warnings are not available in this edition of the compiler
Ooops.
Why Don't Software Developers Use Static Analysis Tools to Find Bugs?
91–100 of 130 posts
Re: Why Don't Software Developers Use Static Analysis Tools to Find Bugs?
#92Mainly 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.
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.
Re: Why Don't Software Developers Use Static Analysis Tools to Find Bugs?
#93Earlier quoted context omitted.
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.
Re: Why Don't Software Developers Use Static Analysis Tools to Find Bugs?
#94Earlier quoted context omitted.
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.
Re: Why Don't Software Developers Use Static Analysis Tools to Find Bugs?
#95Well, I did it the other way around. When my co-workers drove me crazy. I just launched Findbugs on their Repo/Projects and filed some bugs in the Bugtracker. That is just a matter of 5 Minutes to get them down to the ground and show that they are not that kind of Rockstar-Devs they pretend to be. But never reveal your secret tools! Well, and if they get curious about your magical Bug-Finding-Skills, they are easy to…
using clonedigger for python I found lots of copy/paste code and surprise! where did we find bugs? right in every spot clonedigger pointed out.
Re: Why Don't Software Developers Use Static Analysis Tools to Find Bugs?
#96The Dart analyzer (https://pub.dartlang.org/packages/analyzer) is used by various IDEs and text editors like IntelliJ, Eclipse, Sublime and Atom to provide semantic autocompletion, documentation and inline warnings/errors.
Re: Why Don't Software Developers Use Static Analysis Tools to Find Bugs?
#97Earlier quoted context omitted.
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 -_-'
Re: Why Don't Software Developers Use Static Analysis Tools to Find Bugs?
#98Mainly 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.
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.
Re: Why Don't Software Developers Use Static Analysis Tools to Find Bugs?
#99Earlier quoted context omitted.
This reasoning makes no sense to me. It's like: Alice: "Doing X will prevent bugs like Y!" Bob: "Oh, but it does nothing for bugs like Z. I just won't bother at all, then". Why would you not want to try and remove an entire class of bugs if it were within your power to do so? Just look at all the effort companies like Facebook have poured into exactly this kind of problem with things like Hack and Flow (which make us…
I think you're missing each other in terms of what static typing you mean. Haskell or ML style static typing is very useful, completely changes the way you do things and gives you many guarantees. C or Java static typing is almost useless with regards to bugs (see null) and serves mostly to annoy you. It has many of extra costs of stronger static typing, but gives you very little of the benefits.
C static typing can be very useful, if you are able to use it effectively.
There is, of course, a tremendous pile of things it doesn't do well, and a bunch of ways you can make it less useful for yourself, but the last C project I worked on I found it a tremendous help in refactoring compared to the nightmare I would have had without it.
Re: Why Don't Software Developers Use Static Analysis Tools to Find Bugs?
#100Static analysis tools are great for simple bugs. However, most compiler tools already fix these simple bugs. If there is a class of bugs not addressed by a compiler, most developers have a script to catch these. It may not find the harder to detect bugs (such as those arising out of nested calls), but it gets the job done. The complex tools pushed out by the static analysis guys usually has a high false positive rate that at first becomes annoying to use and later is completely ignored.
As for more complex bugs, most developers are aware these bugs exist but do not want to fix them immediately. The reason is on many occasions, these bugs represent some bigger problem in the code base that requires significant re-factoring. And applying the quick fix as suggested by the code analysis tool simply buries these problems instead of fixing them the right way.