Home > Software > Code analysis and review

Code analysis and review


In a big team, with many developers involved, code review is essential. But do you have the tools to do it?
Certainly. As I was lately using Eclipse (and I want to do as much as possible in one place) I will further describe some plugins that will help you accomplish that.

Code analysis

I will start with some automated code analysis tool.
I’m using FindBugs and PMD. My goal is to have 100% clear report from FindBugs. On PMD, things are a little bit different, and this plugin is reporting even the slightest problems, even though they aren’t of real concern. But this tool has a useful feature, Find Suspect Cut and Paste to find duplicate code. It does not always do the best job, but increasing the tile size can help.

If you need report metrics about your project a good choice can be Metrics. It calculates a lot of metrics, it can do a dependecy analysis, export the reports into XML.

All these tools can be easily installed in Eclipse from the update sites. Then they will provide contextual menu items to run the analysis on file, folders or the entire project, displaying the results in specific views. They can be integrated in your build process, running as Ant tasks and generating reports in various formats, usually XML.

Code review

I love automation, but human intervention is the ultimate factor. In this case – code review. And the tool here is Jupiter. I must say that I love this tool – easy to use and right on target. Unlike other similar tools, it does not require an additional web application or any additional software. It stores everything on files, which can be maintained in your source versioning system, to coordinate and communicate the review between team members.
I will enter here in a few more details.
After installing Jupiter like any other Eclipse plugins and restarting the environment, you will have to setup a review, to keep everything under the same roof. So, click on the project that you want to review, then Properties > Review > New … A wizard will start to configure your review (you can edit these settings at a later time). Here you can setup

  • the review name and description;
  • the files to be reviewed – you can leave blank for all;
  • the reviewers – I would suggest to use the developer’s email addresses;
  • review folder (where Jupiter stores all the review data) – I would suggest to use /review or /.review and to store this into your versioning system, along with the file /.jupiter (where Jupiter stores the metadata about all the reviews). Be careful, if you keep the latter on the versioning system, that one contains who is the author of the review, which should be different on each machine;
  • issue types and severities – the default ones seem pretty good and they’re explained here;
  • the author of this review;
  • the default values for fields like type or severity;
  • filters for the issues for different phases of review: individual – when issues are submitted, team – when issues are discussed and assigned and rework – when issues are addressed

Now you are all set up and good to … REVIEW. Just go to a line in a file in editor, right click and select Add Review Issue … The Review Editor view will open and there you can enter all the details. You can browse the existing issues using the Review Table view and navigate directly to an issue in the file, notice the purple icon on the left side of the editor or the small purple line on the right side. Another useful feature is the ability to customize different filters, even different for each review phase.

If you will store your review files on SVN (or other versioning system), after update/checkout, don’t forget to modify in the configuration that you are the reviewer (and not the one that committed the last version). Just go to Project Properties > Review > Select a review > Edit > Author and select your name from the list. Also after update don’t forget to refresh the project and the review.

I like Jupiter, because it does not require another server or software installation, it keeps everything in some XML files so you can use your favorite versioning system and it is easy to use and straightforward. It is like a local code issue tracker, but you can also synchronize across a team using, let’s say, Subversion. And, it is integrated in Eclipse and you can do everything in one place.

Summary

Tool Eclipse update site
FindBugs http://findbugs.cs.umd.edu/eclipse/
PMD http://pmd.sf.net/eclipse
Metrics http://metrics.sourceforge.net/update
Jupiter http://jupiter-eclipse-plugin.googlecode.com/svn/trunk/site/
Categories: Software Tags:
  1. mConDev
    March 9, 2011 at 3:08 pm

    The Metrics update site does not work. Do you know an alternate site to get the plugin ?

    • March 10, 2011 at 6:31 pm

      You can download it from SourceForge and install it directly from the package.

  2. July 15, 2015 at 12:20 pm

    Hi,

    How to maintain the bugs report in excel sheet or some other PDF. Could you please help me. this is very help full for me.

    Regards,
    Basam P

    • July 15, 2015 at 12:31 pm

      Excel sheets and PDFs are not appropriate for maintaining bugs. These are documents, not issue trackers.
      The problem is that these are not centralized, cannot be edited simultaneously by multiple users and you don’t have notifications. Synchronizing multiple user edits will be an extreme challenge.
      If you’re using something like Google Docs, some of these problems are solved.
      But why using excel sheets and PDFs instead of issue trackers? Moreover, a lot of SCM, like Gitlab or Github, nowadays also include issue trackers.

  3. July 15, 2015 at 12:26 pm

    Hi,

    How to maintain the Jupiter review files report in excel sheet or some other PDF. Could you please help me. this is very help full for me.

    Regards,
    Basam P

    • July 15, 2015 at 12:32 pm

      Jupiter review files report in excel sheets? Why?!?

  1. No trackbacks yet.

Leave a reply to Adrian Cancel reply