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

101–110 of 130 posts

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

#101

Post by Consultant32452 »

geromek wrote: post #14

I think the reason is fairly simple: even the most evident-no-doubt clear SQL Injection vulnerability found by a SCA tool may never be exploited at all under production (for instance because of a WAF). Then the obvious benefits of static analysis are not that obvious for your employer. Sometimes we forget companies do not want a perfect code or the best possible well designed software but a product that make them ear…

Gosh I'm the opposite. I do consulting work and whether my clients want it or not the work I provide them utilizes several code analysis tools: findbugs, cobertura, checkstyle, and PMD. I simply don't write code without those tools present if it's even remotely reasonable to do so.

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

#102

Post by crdoconnor »

falcolas wrote: post #87
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.

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

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.

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

#105

Post by shavenwarthog2 »

As a Python programmer, I live and die over Pylint. Yes it's annoying to configure it, but it saves me hours every _day_. The two biggest benefits are:

- syntax or undefined variables in exception handlers

- showing which modules are no longer used, so we can have a clearer import block

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

#107

Post by Gravityloss »

glogla wrote: post #58
PinguTS wrote: post #38

Earlier quoted context omitted.

I am from engineering background and not soley a software guy, so forgive me my different view on this topic. I learned, that every error you can fix early on will cost you about 10x to fix in the next stage. All the new principles like Agile have not changed that.

I think the idea is not that it's not worth to fix errors as soon as possible (which it is), but that static analysis tools provide too many false positives and too many non-errors to be useful.

I guess you can combine the points: if you use static analysis from the start / have it configured right then the amount of false positives should stay relatively low.

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

#108

Post by omouse »

shavenwarthog2 wrote: post #105

As a Python programmer, I live and die over Pylint. Yes it's annoying to configure it, but it saves me hours every _day_. The two biggest benefits are: - syntax or undefined variables in exception handlers - showing which modules are no longer used, so we can have a clearer import block

could you share your pylintrc for others to learn from?

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

#109

Post by AnimalMuppet »

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.

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.

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

#110

Post by AnimalMuppet »

frobozz wrote: post #42
tunesmith wrote: post #10

It's possible to ship working dynamically-typed code that is just absolutely littered with problems that static-analysis tools complain about (even to the point of being "accidentally correct"). So then you can spend a bunch of hours making it compliant, and it's a big refactor that takes a while for other people to review/qa/approve, meanwhile the product folks are grousing about the time it's taking away from the s…

If you had static analysis in from the start, that wouldn't be a problem. If you add static analysis to a messy project, define success thresholds based on the current violation count, and/or disable violation categories that you can live with. The rule then should be "don't make it worse, try to make it a bit better when you can", rather than "don't commit anything to main until the checker says it's perfect".

Our approach was, fix the really horrible ones now, and don't add new ones that we care about. Then, as we have time, fix the next-most-horrible ones.
Post reply on HN