Friday, May 8, 2009

Perform Static Analysis using Rational Software Analyzer

Static Analysis is a core practice in eXtreme Programming to detect code quality issue at an earlier phase. Rational Software Analyzer is a powerful and flexible tool to perform static analysis, to improve code quality.

Rational Software Analyzer has been integrated into RAD/RSA 7.5 from 2008. You can easily use it to check one code file or a batch of code files. Of course, you can download and install a stand alone version if you don't use RAD/RSA.

1. Start from the Configurations:
   

Click the Software Analyzer Configurations ... to open configuration window. Create a new configuration for your analysis, and the embedded SA version include totally 211 rules for code analysis. As I know the standalone version provided more domains and rules. But I believe you can install the whole set rules yourself if you need. At lease I found the 211 rules are enough for my project. Even I don't need all of them.

In the configuration rules tab, you can customize which rules you need for your analysis work. A nice thing is you can also export your rules set to share with others, which ensure the whole team developers can analysis code using exactly same rules.
   

2. Right click on the file, or package, or whole project which you want to analyze, select "SoftwareAnalyzer - " to start, you can see the analysis result (errors or warnings) in the Java Code Review tab. Fix those issue one by one. Sometime, you can see the "Quick Fix" in right click menu.
   

Best Practice:

But sometimes, we are unable to fix all errors or warnings in the analysis result for various reason. In this case, the developer should provide a proper explanation for the unfixed items.. This is a very good practice I believe. But for those unfixed items, if another developer works on the same code in future, he will meet the same error or warning again. He have to spend time to analyze it again, that's a time waste!

So my suggestion is that the developer must add some javadoc comment in the code where the error or warning is marked and it isn't fixed, then the javadoc comment can save another developer's time in future. For such a case, I think we don't need work out and formal document to record that as the document will never be updated or read by others possiblily.

And for the javadoc comment content, maybe we can include these information:
1. the violated rule name;
2. the explanation why you didn't fix this error or warning;
3. comment date and develper's name, for possible future discussion

A feedback from Tim Shanahan is we can consider to use annotations mechanism instead of javadoc. The advantage an annotation could provide the ability to dynamically decide whether to count or report items that have been documented. Maybe this is a better idea, will try it later.