Static Source Code Analysis tools for Java

From Slashdot | Do Static Source Code Analysis Tools Really Work?

Yes, absolutely (Score:5, Informative)

by Llywelyn (531070) on Monday May 19, @01:02PM (#23464190)

FindBugs is becoming increasingly widespread on Java projects, for example. I found that between it and JLint I could identify a substantial chunk of problems caused by inexperienced programmers, poor design, hastily written code, etc. JLint was particularly nice for potential deadlocks, while FindBugs was good for just about everything else.

For example:

  • Failure to make null checks.
  • Ignoring exceptions
  • Defining equals() but not hashCode() (and the other variations)
  • Improper use of locks.
  • Poor or inconsistent use of synchronization.
  • Failure to make defensive copies.
  • “Dead stores.”
  • Many others []

At least in the Java world, I wish more people would use them. It would make my job so much easier.

My experience in the Python world is that pylint is less interesting than FindBugs: many of the more interesting bugs are hard problems in a dynamically typed language and so it has more “religious style issues” built in that are easier to test for. It still provides a great deal of useful output once configured correctly, and can help enforce a consistent coding standard.

Low startup cost and great benifits (Score:5, Insightful)

by iamwoodyjones (562550) on Monday May 19, @01:04PM (#23464208)

I have used static analysis as part of our build process on our Continous Integration machines and it’s definitely worth your time to set it up and use it. We use FindBugs with our Java code and have it output html reports on a nightly basis. Our team lead comes in early in the morning and peruses them and assigns them to either “Suppress” or fix the issues. We shoot for zero bugs either through suppressing them if they aren’t bugs or by fixing them. FindBugs doesn’t give too many false positives so it works great.

Could this be just another trend?

I don’t worry about what’s “trendy” or not. Just give the tool a shot in your group and see if it helps/works for you or not. If it does keep using it otherwise abandon it.

What kind of changes did the tools bring about in your testing cycle?

We use it _before_ the test cycle. We use it to catch mistakes such as “Whoops! Dereferenced a pointer there, my bad” before going into the test cycle.

And most importantly, did the results justify the expense?

Absolutely. The startup cost of adding static analysis for us was one developer for 1/2 a day to setup FindBugs to work on our CI build on a nightly basis to give us HTML reports. After that, the cost is our team lead to check the reports in the morning (he’s an early riser) and create bug reports based on them to send to us. Some days there’s no reports, other days (after a large check-in) it might be 5-10 and about an hour of his time.

It’s best to view this tool as preventing bugs, synchronization issues, performance issues, you name it issues before going into the hands of testers. But, you can extend several of the tools like FindBugs to be able to add new static analysis test cases. So if a tester finds a common problem that effects the code you can go back and write a static analysis case for that, add it to the tool and the problem shouldn’t reach the tester again.

[Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

Comments are closed.