aspose file tools*
The moose likes IDEs, Version Control and other tools and the fly likes static analysis tools and its impact on code review Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "static analysis tools and its impact on code review" Watch "static analysis tools and its impact on code review" New topic
Author

static analysis tools and its impact on code review

manish ahuja
Ranch Hand

Joined: Oct 23, 2003
Posts: 312
Hi All,

I would like to know your opinion on the same. With the increase in the usage and popularity of static analysis tools like PMD, Find Bugs in application development, how does this impact the process of manual code review/peer review. Do you feel these tools help cut corners and also are they more effective than the normal eyeball based code review process.
Can we have more reliance in these tools and cut down on time allocation or toss-out the manual code review process.

Let me know your thoughts.


Thanks.
Peter Johnson
author
Bartender

Joined: May 14, 2008
Posts: 5830
    
    7

From personal experience, I have found that code reviews tend to expose areas where the coder has not followed coding guidelines, but rarely, if ever do code reviews expose defects (I have too often sat in code reviews for code that I knew had certain defects but never were those defects noted by any of the reviewers). With the various tools now built into Eclipse, for the last project I worked on, I configured Eclipse to mark coding guideline infractions as warnings and then prohibited anyone from checking in any code that contained a warning, unless there was a comment in the code explaining why the coding violation was necessary. I also supplied a formatting config and required everyone to reformat the source before saving. I added similar guideline checks to checkstyle and various other tools for ant and maven builds.

The one nice thing about the Eclipse warnings is that after a while you just tend to write warning-free code.


JBoss In Action
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30537
    
150

Manish,
I still do plenty of code reviews. Just different types. Every so often, I'll run the static analysis tool with really strict settings. Most of these are things that I would never recommend someone change. Yet somehow I notice there is a correlation between "bad" code and code that has lots of these issues. Which lets me focus my manual code review on more troublesome code.

I also use code reviews for verifying the code follows the algorithm, checking newer people are following the team architecture or recommending coding techniques to reduce the amount of code needed. (for example someone wrote their own quicksort once.)

In other words, I let the static analysis tool do the brute force checking and I look at things it can't check.

I also request a code review of my own code periodically. Humans give good suggestions and help you improve.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: static analysis tools and its impact on code review