Code analysis tools are great, but don't think that static and dynamic code analysis tools can substitute the old fashioned peer review between humans.
When we talk about code reviews we can find three fundamentally different types of code reviews:
My personal favorite is - as you may see in the title of this article - the more informal 'lightweight code reviews', but also tool based analysis and formal software inspections are useful in the right context.
Don't get me wrong I believe in numbers and tools, but automated code review tools will never replace peer reviews between humans, because code reviews have two complete different benefits:
In the following, the three main types of review will be discussed in more detail.
The big advantage is that you find more findings in predefined fields than in simple lightweight code reviews. On the other hand, the effort is large and makes just sense in projects with strong requirements of quality. Therefore inspections can mainly be seen in the defence industry, aviation and medical fields.
Some years ago I have been involved in the introduction of typical Fagan Inspection in a large IT organisation. It was a disaster, because it was just to much for the beginning. My estimation is that about 10% of the teams had no problem with the new process, but the rest was either convinced that there is no benefit at all or it is to time consuming. The interesting aspect is that the teams with no or less problems have had - in most of the cases - already experiences with informal lightweight code reviews.
There are two categories of tools static code analysis tools and support tools to document and manage reviews.
The use of these tools on an daily base is strongly recommended and works best in combination with Sonar . It uses - besides others tools - Findbugs, PMD and Checkstyle for analysis. One big advantage is the Eclipse plugin which fetches the centrally managed rule set from the Sonar server and provides in this way a simple unified interface to the developer.
My personal opinion is that the use of the first category 'static code analysis' is a absolutely must in every development and/or maintenance team. This is increasingly popular, but at second glance it is more a task management of warnings from the static code analysis tools.
As the title implies this type of code review is my favorite n most development activities. Lightweight code reviews are easy to introduce and give more freedom to exchange know-how between two or more developers.
Figure 1: Peer review protocol with hand written comments
This it the best way to start with reviews in a team. The best is to print out the source code to be reviewed and take a ball pen to mark all findings during the peer review on paper. Reviews on paper have the big advantage that you can focus on the code and avoid all overhead like in Fagan Inspections. Usually the acceptance from developers is good and you can still document the reviews and fixing of found defects.