Live data from Hacker News

Why Don't Software Developers Use Static Analysis Tools to Find Bugs?

viva64.com

71–80 of 130 posts

Re: Why Don't Software Developers Use Static Analysis Tools to Find Bugs?

#71
post #53
post #50

Earlier quoted context omitted.

Why? You'd just keep the code in SSA and diff whenever the user adds code - you need to create the form _once_ but after you've created it diffing it should be reasonably fast - the creation can be done at project creation time and it can be changed on-line and incrementally. I'm not sure if tools actually do it but it definitely sounds possible.

How would maintaining a SSA representation of the code help detecting dead code paths? Doing so requires reasoning about possible truth values of conditions and is in general equivalent to the halting problem and therefore undecidable. You could only spend the cycles available in real time and that will in a certain number of cases be enough to solve the problem but there will also be instances requiring more cycles…

Going incremental is another option: if the analysis was done overnight and you only made a few changes, there shouldn't be much to do to "repair" the analysis according to your changes.

But the PL community is not really good with incremental computations, especially ones that must consider arbitrary code changes (which, for example, can cause non-monotonic movements in your lattices).

Re: Why Don't Software Developers Use Static Analysis Tools to Find Bugs?

#72
post #67

Earlier 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

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

Re: Why Don't Software Developers Use Static Analysis Tools to Find Bugs?

#73

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.

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

Re: Why Don't Software Developers Use Static Analysis Tools to Find Bugs?

#75

Earlier quoted context omitted.

> The benefits of static typing (complie-time checks) are grossly exaggerated. If the claims were true, Java itself and Java projects would be much less buggy.) I have no stats here (and neither do you :)), but based on my experience, Java code does tend to be much less buggy when compared with dynamic-typed code, keeping the features and quality of developers the same. Of course, logical bugs don't get caught by sta…

>Java code does tend to be much less buggy when compared with dynamic-typed code I only see this happen when both the Java code and the dynamically typed code both have zero tests. IME, once you actually start taking integration testing seriously and actually exercise your code even just a little , the benefits of static typing evaporate pretty quickly.

Then you indirectly agree that java code requires less tests, which means static typing helps!

Re: Why Don't Software Developers Use Static Analysis Tools to Find Bugs?

#76
post #48

Earlier quoted context omitted.

Indeed, those real time checks are currently just a convenience, not anything really essential.

Real-time feedback is a usability concern, not just a convenience. Of course, it is not always possible, and we have to settle for non-real-time feedback, but there are definitely usability costs!

[deleted]

Re: Why Don't Software Developers Use Static Analysis Tools to Find Bugs?

#77

Very interesting article! I am developing static code analysis tools for Python myself ( https://www.quantifiedcode.com ) and have thought a lot about this problem as well. Since we offer a SaaS solution instead of an IDE plugin the boundary conditions are a bit different for us (e.g. we have less strict "realtime" requirements but the feedback time is also longer), but the basic question is the same: Why doesn't eve…

It looks like it takes quite a while to analyze :-( It just says Waiting for analysis to start (queue position: 46)

Re: Why Don't Software Developers Use Static Analysis Tools to Find Bugs?

#78
post #34

I used lint for C some 20 or 25 years ago, then moved to using dynamical languages (Perl, Ruby, JS.) Not much use of static analysis tools for those languages I thought (but for example check https://www.infinum.co/the-capsized-eight/articles/top-8-too... ). I used Java sometimes and took advantage of Netbeans/Eclipse's hints about Java code but I use emacs for everything else (some vim too). I used jslint on a JavaS…

> it's useless to define a var inside a loop

No, `for` loops have nothing to do with JavaScript scope. What you probably ran into was a situation like this:

    for (var i = 0; i 
In this case, as a stylistic preference, JSLint will suggest you remove the second var, or you can also declare it at the top of the scope and then omit the var declarations in the `for` loops anyway.

And yes, strictly speaking, the latter option is the most performance-oriented, although most JS interpreters optimize for this not anyway such that it makes no difference.

But this JSLint suggestion really has nothing to do with the `for` loop, this situation would have the same effect:

    var i = 0;
    i++;
    use(i);

    var i = 0;
    i++;
    use(i);
`for` loops have no impact on scope, which is mostly functional, with some prototypical complexities thrown in for good measure.

Re: Why Don't Software Developers Use Static Analysis Tools to Find Bugs?

#79
post #23

Because neither an advanced type system nor static analysis could catch bugs in program logic?) The benefits of static typing (complie-time checks) are grossly exaggerated. If the claims were true, Java itself and Java projects would be much less buggy.)

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…

No one said that it doesn't catch different types of "easy" type-mismatch bugs (which dynamic but strong typed languages will catch too at the first test run) - Clang, for example, warns a lot, and there are industry-strench static analysers for C. Nevertheless complex code is usually buggy. Integer overflows is very good example of a bug by human programmers.
Post reply on HN