Brainstorming techniques for Enhancing Findbugs - implement a planned feature.

While reading through the Findbugs manual, a section jumped out at me: Chapter 8, Filter Files. Since I had previously mentioned I would have to find out the level of support Findbugs had for excluding error reports, I chose to skip the first 7 chapters to have a quick glance.

Even before the introduction began, another comment caught my eye:

Planned Features
Filters are currently only supported by the Command Line interface. Eventually, filter support will be added to the GUI.

Being naive, I thought the support for filtering files would already be included in the GUI version of Findbugs. This would represent a serious candidate for a choice of how to enhance Findbugs - taking on the work of implementing filtering options through the GUI.

The filtering is done through a matching scheme, which offers a flexible and powerful way to define which bugs are excluded. A set of the possible ways to match bugs are:

1. Match all bug reports for a class.
2. Match certain tests from a class by specifying their abbreviations.
3. Match certain tests from all classes by specifying their abbreviations.
4. Match certain tests from all classes by specifying their category.
5. Match bug types from specified methods of a class by their abbreviations.
6. Match a particular bug pattern in a particular method.
7. Match a particular bug pattern with a given priority in a particular method.
8. Match minor bugs introduced by AspectJ compiler (you are probably not interested in these unless you are an AspectJ developer).
9. Match bugs in specific parts of the code base
10. Match bugs on fieds or methods with specific signatures

With the exclusion matchers available, it would be possible to exclude specific bugs in as fine a granularity as a method in a class. It would also allow wider matching, like 'ignore all of this bug type in this list of packages'. Using information attached to each bug report, such as location or bug type, the GUI would be able to provide a choice of potential matchers, greatly reducing the cost of reducing false positives.

Providing a GUI of defining these exclusion filters would have the following advantages:

• The bugs to stop reporting are controlled by the developers rather than an algorithm. Developers are a cynical bunch, and it would probably take a lot to convince them to place their faith in machine learning techniques. NB: it may be interesting to hold a survey with this, with Findbugs users.
• Filters are already an established model for removing bug reports. Though currently accessible through the command line, they do have documentation, and will no doubt have users who have became familiar with the technique. This would reduce the barrier to entry for using the developed system.
  
• Including filtering in the GUI is a planned feature. This would greatly improve the chances of the developed system being somehow involved with the Findbugs project.
• Completely compatible with the crowdsourcing technique described in an earlier post, but would still provide a benefit for single or small development teams.
• The GUI would be able to recognise cases where, rather than specify an exclusion filter, an annotation could be used. For instance, when it's known a parameter is not null, rather than ignore the error, place Findbugs' @Nonnull annotation on it.
  

Some disadvantages (including personal rather than technical) are:

• Implementing a GUI for Findbugs is unlikely to require machine learning techniques, removing the necessity for me to work with them (this may be a hidden benefit :-P)
• False positive removal would still be a manual process, which is a bit of a burden. Though there is always going to be the trade-off of developer burden vs. trustability I think.
  

Not that I'm investing in this avenue for enhancing Findbugs, but it's probably my favoured technique so far.