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.
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.
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.
Also, I recommend you to try Incremental analysis mode in PVS-Studio. It corrects on its own and doesn't distract programmer. http://www.viva64.com/en/b/0305/#ID0ECLDK
Nice paper from 2013, but I was confused at first how it related to the blog. This paragraph just after the abstract explained, but I missed it the first time through:
The original article in PDF[1] was published at the NCSU COE
People site. It was translated and published at our blog
by the authors' permission. At the end of the article[2], we
added a short section about the PVS-Studio analyzer, where
we describe which of the recommendations suggested in the
article are or aren't implemented in our tool and why.
Yes, I also found this quite confusing. The way this paper was attributed seems quite sloppy. It mentions previous publication at the "NCSU COE People site" and gives a link, but omits mention that this paper was originally presented at the International Conference on Software Engineering (ICSE 2013):
These notes shouldn't have been tacked onto the abstract. Instead they should have been clearly separated from the paper itself.
In addition, the PVS Studio team "added a short section" which appears as if it were a modification to the paper, and and it also appears in the augmented table of contents. If one is not reading carefully, or if the section heading has scrolled of the top of the screen, one might be misled into thinking the "added section" was also authored by Johnson et. al. instead of by the PVS Studio team. The "added short section" should also have been published entirely separately.
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 this function. The function asks that you check that the integer falls into the length of the array that you are also passing in and that it's a multiple of two. Also, the function doesn't promise that it won't return a null value and you are using the result without checking it first. Basically looks at your entire project and can work out code paths across methods.
There's worlds of a difference. ReSharper is definitely useful, but doesn't come close to what proper static analysis can do. If you like what ReSharper is doing for your codebase I thoroughly recommend having a look at Code Contracts (it's a free Microsoft Research project).
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.
The problem with contracts and static analysis is that large projects are often so tangled up by the time that someone (me) applies contracts to them that the static analysis takes days or weeks of execution time.
I add the contracts anyway because they really do help find bugs at run time too and also act as executable comments.
I don't know how is why! (And if I learned, then my coworkers wouldn't know how, so until I got everyone else on board, I would be making the bed only to have them jump all over it again.)
Don't tell me to hunt down random third-party tools that none of my coworkers has heard of, that I have to convince them to adopt, and which each solve a little (usually overlapping) bit of the problem so I have to run all of them in series. That way leads to madness, and horrible one-off UIs developed by people more concerned with their tool's special-snowflake analysis algorithm than its output.
Instead, ship an extensible, plugin-based linter with your language's toolchain (e.g. mix for Elixir, lein for Clojure, etc.) Make its output beautiful. Write one or two simple plugins, and make installing lint-plugins as simple as adding something to the project's dependency file. Then I (and everyone else) will use this stuff.
Given that this article is written by/for pvs studio, which works mostly inside visual studio (you can get it to work outside but it seems to require some amount of setup), anyone using visual studio's too chain has a static analysis tool at their disposal. Also, clang has built in static analysis, and I can't speak for gcc.
In one of my recent projects, we used SonarQube. I had actually never worked with that tool before. What bothered me most was how it marked things as errors but did not explain _why_ they were wrong. When it comes to code style, there's a lot of room for personal opinion, and this just led to me arguing with the architect about whether something is a false positive or not. That time could have been spent writing actual, working code or more unit tests.
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 sprint when it's not a roadmap feature, and as a programmer you might completely believe it's worth the effort to clean up the code, but you're still having to deal with a lot of friction.
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".
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 everyone use static analysis to improve their code?
After having surveyed most of the available static analysis tools I think that part of the answer is that often the tools simply do not provide enough value for developers, especially those analyzing dynamic languages like Python / Ruby / Javascript (for C++/Java the tooling is much better). We are currently trying to change that by developing a new, data-driven approach to code analysis, which (we hope) should improve the quality of the analyses quite a bit and provide better and more actionable feedback.
Part of the problem is also cultural of course: People have different ideas about what "good code" is and they usually do not like having their code critiqued. Using an automated tool rather than manual code review to check some aspects of code quality can be beneficial though, since it is normally easier to accept harsh feedback from a machine than a human.
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 earn money.
My experience is that developers only use those kind of tools if they are forced to by their QA managers of bounded by contract. Programmers usually don't want to fix or track bugs.
I am saying "Developers do not want :
1 - Pay A LOT of money for advanced solutions that are more than AST checkers (hello SonarQube) or big piles of false positives.
2 - Add overhead to their workflows (more than an IDE plugin is harmful, and what happens with those devs not using an IDE?).
3 - Spend time on figuring out if the static analysis results make sense or not, one by one.
A typical SCA tool can report hundreds or thousands of occurrences for a certain code base. How are developers going to deal with them?
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.
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.
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.)
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 use of OCaml).
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.
Static analysis is more than just static typing. Notably, it is possible to leverage static analysis for solid gains in reliability against code bases without having to rewrite them to take advantage of a different typing paradigm.
To repeat, you can harden a code base without rewriting it by using static analysis tools. This is not as true with static typing.
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.
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.
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 myself to care on tabs.
However, using some of the more advanced static analysis tools that don't just show where you forgot to do a null check, but also show where you pass in a null value... That is truly impressive and fixes bugs. Even better, these are things that can be used to harden a code base without having to rewrite it.
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...
> 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 static typing. But it helps a lot when refactoring code, or collaborating on the same codebase with many people, or changing someone else's code. These things become really important once the code base hits a certain size.
>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.
Have you looked at the clang analyzer that's integrated into Xcode (http://clang-analyzer.llvm.org/)? It doesn't catch everything, and sometimes gives false positives, but it is quite amazing how it visualizes problems in the program flow, going through several levels in the call hierarchy, following variable assignments over function calls, etc... in a few cases I was convinced that a problem was a false positive until I really took the time to understand what the static analyzer is trying to tell me and it turned out to be actual bugs.
In my opinion it is mostly poor integration into the coding workflow, and poor visualization of the analyzer warnings that lead to too little use of static code analysis, and another is a too wide-spread 'if it works at all, ship it' mentality.
I would not say grossly exaggerated, especially for languages with stronger type systems than Java. But the worst bugs I've encountered definitely came from code behaving exactly as intended. The flawless implementations of terrible, terrible ideas.
There's not much a language can do to protect a programmer from doing nonsense. Terse, explicit languages that are easy to reason about have a slight edge in that they make it easier to grasp the big picture. A powerful type system like that of Haskell can certainly help too. Practices that involves many eyes looking at the code help the most.
>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 wouldnt call Java an "advanced type system". Take a look at Idris then try to say that with a straight face:
>Because neither an advanced type system nor static analysis could catch bugs in program logic
It certainly does if you indeed use an advanced type system.
The problem I have is that there are many cases where the tools are too defensive. If I want to override the tool, I'd typically have to add some annotation in the code to signal to the tool that I am ok with this warning and don't want to see it again. And I, for some reason, just hate adding style checker and static analysis annotations in my code. It just looks ugly to me.
They should. There is no excuse: clang has it for free, Visul Studio, too (Express Editions, since 2013). Also, for Open Source projects Coverity is free.
I do! For cheapness, Flawfinder, CPPCheck, and Product > Analyze in xcode (thanks clang) (the walkthroughs in xcode of how they deduced the problem are really great, blue arrows everywhere, very neat).
EDIT: Additionally, given the changes in C++11 we should be able to push all the work onto the compiler for checking type problems, remove dangerous operations, dangling pointers, naked new/delete and avoid casting where possible. It would make for bug-free software. I know someone who writes their C++ like it is late 80s C and firstly, it's horrible to read. And secondly, it does really dangerous things.
I refactored some code this week that used realloc to allocate memory for a 'vector' (which was a typedef for float*), and then a loop with additional realloc's to allocate memory for each element in that vector, to end up with a matrix 8| This is code that was written in the last few years, too. Welcome to academia :(
I use IntelliJ for my java development. It has a lot of analysis built in (whilst you're writing code). I'm not sure if there are that many static analysis checks (Findbugs etc) that are missing outside of those real time checks?
I can often determine whether someone had used Eclipse or IntelliJ; there tend to be a lot fewer analysis warnings if someone has used IntelliJ (out of the box) => perhaps we need this analysis in real time?
Don't know about IntelliJ, but XCode does real-time analysis as well, but it also has a mode for deep static analysis, which for example does code path analysis for finding dead code paths, even across methods. This kind of stuff would be hard to perform in real-time.
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.
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.
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!
A tool like IntelliJ can do deep analysis off-line and in the background and only tell you about the results. This is a good tradeoff between fast feedback and deep analysis.
I don't exactly know which kind of analyses IntelliJ performs but assuming that they are comparable to what ReSharper does they are quite different from what for example Coverity looks for.
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 JavaScript project a few months ago. It catched a few things I overlooked, I learned a couple of things (example: it's useless to define a var inside a loop) but it's also very opinionated and insisted that I write code in a way that pleases its author. I had to refactor working code to make most of the warnings go away. I ended up with something that worked as well as the original but was much more complicated to read (at least for me). I stopped using it and regretted making all those changes to the code. There are some configuration switches but nothing that could make it work for me. I should check jshint but unfortunately jslint primed me against that kind of tools.
I prefer to catch errors with tests and test coverage tools. They must be used anyway and they bend to me, not the other way around.
It is the "opinions enforced with static analysis" that ultimately annoy me with most analysis tools out there. Things that actually cause bugs, I welcome ways of finding them. Chaining all of my variable declarations together... What?
The sad thing is that the powerful analysis tools are truly amazing and do find things. They just are not what the majority of people have experience with. That does seem to be changing.
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.
pylint is also trivially easy to configure to omit most of these stylistic warnings.
I say this as someone who took 10 minutes to generate and configure the pylintrc for a new project. After taking this time, pylint has been quite useful.
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 < length; i++) {
do blah;
}
for (var i = 0; i < length; i++) {
do more blah;
}
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.
I think that was parent's point. Coming from other languages, it's kind of unexpected that a var defined within a curly brace block (if/for/etc) is actually scoped on the whole function in which it appears and not just that block. Hence it's "useless" to define it within the block/loop -- might as well hoist it outside, it's visible there anyway
That's fine, but making it a default option for all developers on every build wouldn't be suitable for us is what I was saying. I'm fine if it's run on the CI servers, or even if it's a requirement that I submit a "clean" static analysis report with my changes, which can be done by giving me the option (like XCode/Visual studio already do).
> 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.
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.
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.
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
"Out of the 20 people we interviewed, 14 people expressed the negative impacts of poorly presented output. ... Some of our participants felt, however, that false positives and large volumes of warnings would be less burdensome if the way the output is presented was more user-friendly and intuitive."
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.
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 -_-'
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.
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.
I found that specific Sonar issue to be bogus. In addition to breakpoints, sometimes the 's' has is meaningful name that ties the function call with the return value.
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.
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).
'[I]f 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.'
I would be tremendously surprised if that proved to be true in the general case, but it might well be true enough in common cases to be practical. Very interesting notion...
127 comments
[ 2.7 ms ] story [ 188 ms ] threadEverybody I know who actually uses static analysis does so because it's built into their IDE and very easy to use.
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.
Do you not parallel build?
1) PVS-Studio can instead be set to run in background immediately after the edited code has been successfully compiled.
2) PVS-Studio integrates with IncrediBuild. And soon we will publish an article about it. A little spoiler. :)
[2] http://www.viva64.com/en/b/0335/#ID0EU4CK
http://2013.icse-conferences.org/index.html
These notes shouldn't have been tacked onto the abstract. Instead they should have been clearly separated from the paper itself.
In addition, the PVS Studio team "added a short section" which appears as if it were a modification to the paper, and and it also appears in the augmented table of contents. If one is not reading carefully, or if the section heading has scrolled of the top of the screen, one might be misled into thinking the "added section" was also authored by Johnson et. al. instead of by the PVS Studio team. The "added short section" should also have been published entirely separately.
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 this function. The function asks that you check that the integer falls into the length of the array that you are also passing in and that it's a multiple of two. Also, the function doesn't promise that it won't return a null value and you are using the result without checking it first. Basically looks at your entire project and can work out code paths across methods.
There's worlds of a difference. ReSharper is definitely useful, but doesn't come close to what proper static analysis can do. If you like what ReSharper is doing for your codebase I thoroughly recommend having a look at Code Contracts (it's a free Microsoft Research project).
I add the contracts anyway because they really do help find bugs at run time too and also act as executable comments.
Don't tell me to hunt down random third-party tools that none of my coworkers has heard of, that I have to convince them to adopt, and which each solve a little (usually overlapping) bit of the problem so I have to run all of them in series. That way leads to madness, and horrible one-off UIs developed by people more concerned with their tool's special-snowflake analysis algorithm than its output.
Instead, ship an extensible, plugin-based linter with your language's toolchain (e.g. mix for Elixir, lein for Clojure, etc.) Make its output beautiful. Write one or two simple plugins, and make installing lint-plugins as simple as adding something to the project's dependency file. Then I (and everyone else) will use this stuff.
Aside from its code formatting rules, which are just silly. They're easy enough to modify or turn off, though, so there's that.
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".
After having surveyed most of the available static analysis tools I think that part of the answer is that often the tools simply do not provide enough value for developers, especially those analyzing dynamic languages like Python / Ruby / Javascript (for C++/Java the tooling is much better). We are currently trying to change that by developing a new, data-driven approach to code analysis, which (we hope) should improve the quality of the analyses quite a bit and provide better and more actionable feedback.
Part of the problem is also cultural of course: People have different ideas about what "good code" is and they usually do not like having their code critiqued. Using an automated tool rather than manual code review to check some aspects of code quality can be beneficial though, since it is normally easier to accept harsh feedback from a machine than a human.
Sometimes we forget companies do not want a perfect code or the best possible well designed software but a product that make them earn money.
My experience is that developers only use those kind of tools if they are forced to by their QA managers of bounded by contract. Programmers usually don't want to fix or track bugs.
If that it true, than I don't want to work with them.
A typical SCA tool can report hundreds or thousands of occurrences for a certain code base. How are developers going to deal with them?
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.
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.)
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 use of OCaml).
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.
To repeat, you can harden a code base without rewriting it by using static analysis tools. This is not as true with static typing.
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.
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 myself to care on tabs.
However, using some of the more advanced static analysis tools that don't just show where you forgot to do a null check, but also show where you pass in a null value... That is truly impressive and fixes bugs. Even better, these are things that can be used to harden a code base without having to rewrite it.
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...
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 static typing. But it helps a lot when refactoring code, or collaborating on the same codebase with many people, or changing someone else's code. These things become really important once the code base hits a certain size.
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.
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?
In my opinion it is mostly poor integration into the coding workflow, and poor visualization of the analyzer warnings that lead to too little use of static code analysis, and another is a too wide-spread 'if it works at all, ship it' mentality.
There's not much a language can do to protect a programmer from doing nonsense. Terse, explicit languages that are easy to reason about have a slight edge in that they make it easier to grasp the big picture. A powerful type system like that of Haskell can certainly help too. Practices that involves many eyes looking at the code help the most.
I wouldnt call Java an "advanced type system". Take a look at Idris then try to say that with a straight face:
>Because neither an advanced type system nor static analysis could catch bugs in program logic
It certainly does if you indeed use an advanced type system.
EDIT: Additionally, given the changes in C++11 we should be able to push all the work onto the compiler for checking type problems, remove dangerous operations, dangling pointers, naked new/delete and avoid casting where possible. It would make for bug-free software. I know someone who writes their C++ like it is late 80s C and firstly, it's horrible to read. And secondly, it does really dangerous things.
I can often determine whether someone had used Eclipse or IntelliJ; there tend to be a lot fewer analysis warnings if someone has used IntelliJ (out of the box) => perhaps we need this analysis in real time?
I used jslint on a JavaScript project a few months ago. It catched a few things I overlooked, I learned a couple of things (example: it's useless to define a var inside a loop) but it's also very opinionated and insisted that I write code in a way that pleases its author. I had to refactor working code to make most of the warnings go away. I ended up with something that worked as well as the original but was much more complicated to read (at least for me). I stopped using it and regretted making all those changes to the code. There are some configuration switches but nothing that could make it work for me. I should check jshint but unfortunately jslint primed me against that kind of tools.
I prefer to catch errors with tests and test coverage tools. They must be used anyway and they bend to me, not the other way around.
The sad thing is that the powerful analysis tools are truly amazing and do find things. They just are not what the majority of people have experience with. That does seem to be changing.
I say this as someone who took 10 minutes to generate and configure the pylintrc for a new project. After taking this time, pylint has been quite useful.
No, `for` loops have nothing to do with JavaScript scope. What you probably ran into was a situation like this:
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:
`for` loops have no impact on scope, which is mostly functional, with some prototypical complexities thrown in for good measure.Sophisticated solutions tend to fail from time to time when applied. And when they fail they are tossed aside for simpler more resilient ones.
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....
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.
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.
Sounds like you're in the majority.
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).
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 -_-'
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.
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.
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.
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).
I would be tremendously surprised if that proved to be true in the general case, but it might well be true enough in common cases to be practical. Very interesting notion...