There are a couple of reasons using IDEA could be a good choice:
* it's pretty big, approximately 1,450,000 lines of source statements (measured using SLOCCount)
* it's completely unfamiliar to me. This may seem like a strange thing to call a benefit, but I'll probably explain this in a later post. The system will be evaluated against a known code base as well.
* the timing is particularly fortunate.
This last point is the most crucial and needs explaining. The view (albeit a simplistic one) of open source software is that it is not under the same pressures as commercial software, and may not have justified adopting Findbugs as part of their process. Commercial software is likely to have less "casual eyeballs" on the source, whereas a project like Eclipse has thousands of contributors, increasing the likelihood that Findbugs was used to develop for it. More specifically for IDEA, it's unlikely that Findbugs is used there - I'm sure the authors would be proud to claim usage on their "Users and Supporters" page. What this all means is that I can now freely inspect a code base which has not already benefitted from the use of Findbugs. A code base for a real, used, respected product.
And what a tasty code base it appears to be, so ripe with bug reports!
The results of running Findbugs (1.3.9-rc1), with default settings, is displayed in the charts below.
Weighing in with 2,872 bug reports, hopefully the IntelliJ IDEA source can act as the larger end of the codebase spectrum. Folding in the 'unfamiliar' end of the spectrum, that leaves me requiring a small, familiar codebase to evaluate with. The 3rd Year Group Project Gizmoball system would probably fit the bill there.
Not that there'll be any bugs in our code, of course...
No comments:
Post a Comment