LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Stomping on the Bugs


By Allen Holub
May 1, 2006 — 
Bugs are a big deal. They, of course, inflate the cost of development. I just spent $850 of my client’s money—and wasted most of a day—tracking down what turned out to be a bug in ActiveMQ’s JMS implementation. (So much for “free” software.) Bugs are also the main source of security vulnerability in your program. Hackers attack bugs—it’s that simple.

Part of the bug problem is addressable with process: Test-Driven Development and continuous regression testing are essential practices. Code reviews and pair programming help too. However, none of these “best practices” will find all the bugs.

Computer programs that purport to find bugs have been around for a while. The venerable Unix lint utility did that with C programs. Unfortunately, for every real bug that lint found, it identified 40 or 50 fake bugs, places in the code where there was actually nothing wrong. This huge number of false positives discredited the whole idea of static analysis, of having a computer program find bugs for you.

Fortunately for all of us, we’ve learned a lot since Steve Johnson wrote the original lint back in 1977. I just installed FindBugs (findbugs.sourceforge.net), the brainchild of Bill Pugh and David Hovemeyer at the University of Maryland. This is a breathtakingly useful (and free) tool.

FindBugs finds the sorts of things you’d expect. Unread fields, unused variables and so forth, but it does a lot more.

The basic bug analysis is thorough—much more so than, say, Eclipse’s editor is. For example, it flags a possible null-pointer dereference if a method uses a reference that’s passed as an argument without first explicitly testing for null in various ways. That is, you can get rid of the error by putting an explicit test in an “if” statement, adding an “assert” and so forth.

FindBugs goes way beyond the obvious “correctness” problems, though. It can find performance problems, some threading bugs (like inconsistent use of synchronization), vulnerabilities to hacking, internationalization problems and style errors. The attack-vulnerability bugs are particularly important, since these things slip through code reviews all the time, and the consequences of an attack can be so large.

I personally consider even the “style” problems to be bugs, so I wouldn’t turn off checking for them, even though FindBugs does give you the option. One example of a style FindBug checks is if an inner class never uses any of the outer-class methods or fields and suggests that you make it static. To my mind, it’s an error for this class not to be static since unnecessary runtime overhead is imposed by the nonstatic nature of the class.

Only rarely did FindBugs flag correct code as possibly in error—maybe one bug out of a hundred or so (unlike lint, where perhaps 95 percent of the flagged “errors” were patently false alarms). For example, FindBugs flagged as an “uninitialized read” a line in a constructor where I was testing a field that had been explicitly initialized in the declaration as null.

Since FindBugs is looking at the class file, not the source code, I can see how it wouldn’t be able to tell the difference between this situation and an actual read of an uninitialized field. (Null is the default value when there’s no initializer, so an explicit assignment of null generates no code at all—the assignment is effectively ignored by the compiler.) More to the point, this particular test for null is just plain weird—it’s not the sort of thing that would come up very often in normal code.

Nonetheless, FindBugs does support a “filter” file, which specifies (in XML, unfortunately) those bugs that should not be reported. The resolution is class/method level (i.e., “don’t report this bug if it occurs in that method of that class”). That’s a little course grained, but would have handled the checking-for-null problem I discussed earlier without difficulty. That bug was the only one of that particular type that occurred in the method.

To ice the cake, FindBugs runs fine from the command line, as a GUI utility, as an Eclipse plug-in and as an Ant task.

I think that FindBugs is the best thing since peanut butter. It’s a spectacularly useful tool. From this point forward, I plan to run all my code through FindBugs at least once a day, and correct literally every problem that it finds. All managers everywhere should require programmers to do the same.

I would permit the use of filters for the rare spurious bug, but I’d put these filters under code review so that sloppy programmers couldn’t use the mechanism to hide the fact that they were being sloppy.

Back in the Jurassic, there were a few misguided shops that required that all C code go through lint without errors, but that was insanity. Lint generated too much “noise.” FindBugs is not lint, however. You’d be nuts not to use it.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.


Share this link: http://www.sdtimes.com/link/29281
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading