Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

viva64.com

Post reply on HN
Print view View original

61–70 of 130 posts

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

#61

Post by inglor »

danbruc wrote: post #53
inglor wrote: 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…

> How would maintaining a SSA representation of the code help detecting dead code paths?

Well, if a variable assigned but never appears in a path that might have side effects it's dead. It's only the halting problem if you pretend to catch 100% of cases under all inputs. You can find lots of dead code without it.

For more information about the specific technique of DCE under SSA form see http://grothoff.org/christian/teaching/2007/3353/papers/ssa....

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

#62

Post by stevedonovan »

pmontra wrote: 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…

Ditto and likewise - same applies to pylint, which must have been the most opinionated piece of software I've ever used. The trouble is that there's some very useful warnings buried in the opinion spew - warnings which would be an error in other languages.

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

#63

Post by Alphasite_ »

zamalek wrote: post #60
inglor wrote: post #4

ReSharper (on C# in Visual Studio) and Visual Studio itself do perform static analysis and find out bugs like "possible multiple enumerations of IEnumerable" for you pretty readily, developers also use code coverage tools. Still, good article.

ReSharper does lightweight static analysis - I would venture to go as far as to place it into the "code smell analysis" category. Using something like Code Contracts, properly, drastically changes your outlook on static analysis. ReSharper: you've enumerated this enumerable multiple times. This if statement is redundant. Basically stuff within the scope of a single method. Code Contracts: you've passed an integer to…

I don't know about code contracts, but IntelliJ does have an equivilent, if less advanced version of these as well, using Java annotations. Although it's mostly used for nullability/taint detection ATM.

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

#64

Post by jokoon »

I once was told that any compiler warning message act as static analysis.

I think static analysis is a complex subject, because it can touch some sensitive subject like programming style and other more expert subjects like compiler back end and how the language defines such and such code behavior.

Static analysis should be made more mainstream, it would be such a great way to teach everybody how to write better code, including and especially students.

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

#65

Post by crdoconnor »

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.

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

#66

Post by yeahdude »

crdoconnor wrote: post #65

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.

grep -v

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

#67

Post by rjaco31 »

yeahdude wrote: post #66
crdoconnor wrote: post #65

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.

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

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

#68

Post by crdoconnor »

raz32dust wrote: post #31
dschiptsov wrote: post #17

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

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

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

#69

Post by kasey_junk »

72deluxe wrote: post #28
maccard wrote: post #12

Earlier quoted context omitted.

My compile is already 10 minutes, I don't want to add a static analysis pass to every build thanks.

Why is your compile 10 minutes? Mine is about 20 seconds for ~82000 lines of C++ (not comments), with 43000 header lines and 7669 lines of C (according to cloc), and that's on a 2008 quad-core Xeon Mac Pro. Do you not parallel build?

130K LOC is an extremely small project. 10 minute compile steps are less common than they used to be, but early in my career I would have dreamed for 10 minute compile cycles.

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

#70

Post by seanmcdirmid »

amelius wrote: post #48
danbruc wrote: post #43

Earlier quoted context omitted.

Good static checkers perform pretty deep analyses you can not (yet) do in real time. Real time checking is of course useful but it is no replacement for a deeper static analysis.

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!
Post reply on HN