Stupid Question 103: What are some different types of code reviews?

[To celebrate my first year of programming I will ask a ‘stupid’ questions daily on my blog for a year, to make sure I learn at least 365 new things during my second year as a developer]

There are different types of code reviews

There are different types of code review, and I was curious to see what the different types are- and how many I had personally experienced.

There seems to be three main categories:

**1.**Pair programming (also considered a non-formal type of code review)

**2.**Formal code review

**3.**Non-formal code review

Let’s go through them:

Pair-programming:

Two programmers at the same workstation, one driver and one observer. The roles are switched frequently. I’ve tried this with mixed results, but I like this. To make this happen I often ask my boss for this, or I’ll ask a developer if he has time to sit with me, or if I can sit with him/her.

Formal code review:

A preplanned evaluation process often following a preset way of code reviewing. Never tried this, doesn’t sound to fun really- but probably has its place.

Non-formal code review

Has also a few sub-types:

**1.**Over-the-shoulder

Rather self-explanatory, a second developer watched over the shoulder of the developer writing the code as the developer walks through the code, and of course gives feedback. I do this as much as I can, and to lure other devs into this I set my desk on standing so it’s easier to get them over for a quick review.

**2.**Email pass-around

Can be done using a source code management system or just by literally sending code for review. I’ve done this a lot when I have specific problems, and it does work quite nicely on minor problems and pieces of code.

**3.**Tool-assisted code review

Using specialized tools for review. The only tools I’ve tried are the generic code inspection tools such as JustCode, StyleCop and ReSharper. Not enough for a proper code review in my opinion, but better than nothing. I always strive to have at least one other person review my code.

Which type of code review do you think is the best one? And have I left out anything here? My favorite is over the shoulder with several developers at the same time (often done with a projector screen, snacks and coffee :) )

Comments

What about self review? Once finished, leave it for a few days so it is not fresh in the mind and then take a second look at the code. The brain knows what should be there and it sometimes fills in the blanks. Taking a break should clear the mind of what it thinks should be there and just concentrate on what actually is there.
Of course, you will need other tasks to do while you let the code marinate. 

Very good advice! If you return to a project after a few weeks of and you are completely lost, well... imagine the guy or girl who has to maintain this! 

We do tool assisted, altough I wouldn't call it non formal, as we have some well defined check list of stuff to look at. I personaly like pair programming, as it pushes me to focus (I have problem with short attention spans :P) on what I am doing, and often get instant feedback. 

Hi Iris,

From my experience, pair programming transcends the realms of just being a type of code review -- it really is a tool for creating more robust code than one developer alone, or two developers looking at the same code synchronously.  In other words, the whole is greater than the sum of the parts.

None of these types of code reviews you listed trump the other, or should be treated as mutually exclusive -- you can't compare one type to another, and I would adamantly opine all are indispensable for promulgating knowledge across all developers on the team.

Mike Reynolds 

In "The Pragmatic Programmer" it is stated that _code_ reviews as such doesn't find very many errors. Unit testing does. Time is better spent reviewing code _design_ - choice of patterns and such.

(It is of course useful to review the code of new programmers to see if they understand the common idioms of the language, but that is another story). 

So write code as if you will be condemned to support it for the rest of your life. Think of it as making life easier for the person who has to maintain the code and hope it will be you. 

Last modified on 2012-12-13