Code Review

The Smart Bear Software company have a code review tool that they used in a huge case study with Cisco. From this they drew up some Best Practices. A summary of these is useful for our own code reviews.

1. Review fewer than 200-400 lines of code (LOC) at a time. Beyond this the ability to find defects diminishes.
2. Take your time with code review. Faster is not better. Keep it below 300-500 LOC per hour.
3. You should never review code for more than 90 minutes at a stretch (although you should always spend at least five minutes reviewing code – even if it’s just one line).
4. Author preparation eliminates the majority of defects so try to prepare notes and comments outside of the code for the review.
5. Both author and reviewer should use a checklist as this helps to find omissions. Personal checklists are also useful.
6. Verify that defects are actually fixed.
7. Defects are positive. This is an opportunity to improve the code; for the author and reviewer to work as a team; for developers to unlearn bad habits; and for good mentoring. Defects must not be held against a developer in any way.
8. Hubris matters. Reviewing a fifth to a third of your code will probably give you the maximum benefit with minimal time expenditure and reviewing 20% of your code is certainly better than none.
9. Most effective reviews are conducted using a collaborative software tool to facilitate the review. Review Board is used for our peer review of code.

Gendarme

Gendarme is a code analysis tool that I think is superior to FxCop (although that doesn’t preclude us from using FxCop, too).

I downloaded  the binaries only package and ran the wizard against my assemblies and was impressed by the results. I think this is something I’d like to add as a report to our nightly builds in TeamCity.

Note that it recommends you select the optimise flag in your builds as otherwise the cruft in the IL can trigger false positives.