121–130 of 130 posts
Static 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…
But they are wrong. They do make quite a lot of them. Here's, for instance, a bug database we have collected and keep updating: http://www.viva64.com/en/examples/.
Moreover, some bugs can take quite a while to find, despite being simple. Here's a nice example:
The conclusion is: the bug we had wasted about 50 hours to track was detected at once with the first run of the analyzer and fixed in less than an hour! Source: http://www.viva64.com/en/b/0221/
True, false positives aren't good, but they are not that much trouble. Static analysis tools provide numbers of means to suppress them. At least, we in PVS-Studio do have a lot of false positive suppression mechanisms. But it's a long story, so you'd better refer to the documentation.
Because we already have a better tool for finding bugs: Production users
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 add the contracts anyway because they really do help find bugs at run time too and also act as executable comments.
Earlier quoted context omitted.
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?
Parallel build with 40 cores(2x intel xeons), 32GB ram using Visual Studio. According to cloc, we have 11k C++ files. 18k C/c++ header, with 4.5M lines of C++, and 1.5M C/C++ Header, and 700K C. We use a unity build to speed it up (to 10 minutes) without it, it's roughly 40 minutes.
Earlier quoted context omitted.
You'd be surprised. Probably at both, but I hasten to get it in the conversation that static analysis is more than just static typing. By a long shot. To me, simple static analysis can be over sold to the point that it is worthless. I swear, I see more effort put into detecting tabs versus spaces than I do things that actually reliably cause bugs. Seriously, unless you are writing make files, I just can't bring mysel…
Or, you used a pointer, then checked whether it was null. This is why you keep re-running it, by the way. You had your null check at the top of the function, and then in maintenance someone added something new at the top, not realizing that it needed to be after the null check...
Earlier quoted context omitted.
Then you indirectly agree that java code requires less tests, which means static typing helps!
Nope. The same tests you'd need anyhow to catch logic errors will end up catching type errors. If a test becomes unnecessary if you have static typing then you should never have written it in the first place. It's a bad test.
That seems a very strong - and unsupported - claim. Could you elaborate?
Earlier quoted context omitted.
In Xcode at least there's a 'Build & Analyze" command (cmd-shift-b). What I like to do is to force a deep analyze on every build. Takes a little longer to build but at least I catch some bugs when I introduce them.
My compile is already 10 minutes, I don't want to add a static analysis pass to every build thanks.
Earlier quoted context omitted.
My compile is already 10 minutes, I don't want to add a static analysis pass to every build thanks.
I would wager 10 minutes is far from the norm for most user's builds in X-Code. That being said, analyzing every build seems a bit much.