What is the difference between code reviews and code inspections?

Question

I'm trying to understand the difference between the two. Any help would be greatly appreciated.

Potential duplicate: http://stackoverflow.com/questions/52598/code-walkthrough-vs-code-review

Answer 1

I would say a review is a bit quicker, looking at things like syntax - commenting - naming conventions - best practices

By the same token, a code review would be more in depth - checking for quality and making sure things are working as they are intended.

Answer 2

A code/software inspection is like a peer review. A group of coders examine's software for any defects and reach a concensus on it being usable for the project. One of the major methods used is known as the Fagan inspection.

A code review is like an inspection, but the examiners will basically look at specific blocks of code, and fix defects/bugs that they find. They're better for helping new employees by pointing out parts of the code that could be improved, do not work the way the programmer inteded, or just don't fit the project requirements.

Answer 3

Note: This is strictly speaking from an industry-point-of-view.

I would say that those two terms lack enough widespread definition to do anything but speculation and discussion. I've heard both being used many many times, both in large and small companies, and I've never seen a situation where anyone really considers how their underlying definition differs in terms of work duration or coverage. It's just about inspecting/reviewing code. Both is about making sure code is free of appearent errors and follows all the rules decided upon.

Answer 4

I think of inspections as a subset of reviews, with more formality and better definition. "Could you come take a look at my code?" "How does this look?" are the kinds of questions that lead to code reviews - pair programming is also a kind of code review. Code inspections are more formal meetings, with agendas and preparation. I believe Steve McConnell's Code Complete is where I learned this distinction.

Answer 5

At my previous employer we engaged in essentially three levels of code reviewing.

We would perform a walkthrough of the code (or the design) and that involved essentially no prep work on the part of the participants, other than the author. The major focus of the walkthrough was to discuss the piece of functionality, what problem(s) it was attempting to solve and the approach taken by the author. This helped to make the team or subset of the team aware of a segment of the overall system (it was a fairly large system with dozens of people developing it) and helped to address some issues without requiring much upfront time from the team.

We would perform what we called code/design reviews in-house which involved a group of individuals who independently looked at the product on their own and asked questions and/or wrote comments against the product to provide the author with feedback from the team without the pomp and circumstance of a formal inspection.

Formal inspections involved monkey business like having a moderator and a scribe and N inspectors who sometimes had specific roles. Metrics were kept for some manager's Excel spreadsheet and to make a chart to show at a meeting. I found much of this affair a waste of time, typically, because the in-house reviews were just as or more effective typically. We had formal sign-offs of on the fixes made against the defects and that was necessary, particularly the fixing of critical errors, due to the nature of the software we wrote.

Walkthroughs aren't likely to find a lot of defects but might find some and typically happen earlier in the process.

Reviews tend to find more defects and issues due to the fact that people are tasked to review the product. They do require someone to budget time into the schedule for them, at least from a bean counter's perspective. In actuality, they didn't impact the schedule much because we could generally make time to look at the code.

Inspections, at least for us, were partially a check-a-box exercise, except where safety-critical software was concerned. Then, it was another opportunity to ensure that the software did as it was supposed to do and to get multiple people who should understand the system to take a hard look at what was going on. I think that the environment we were in affected the level of commitment and thus the level of effectiveness of the inspections. Often it seemed that the schedule would be king and inspections would get reduced to box checking events.

Anyhow, I don't know about the industry at large, but that is how we did things.

Answer 6

None. In both cases, the objective is to get better code.

The means may be differents, but the purpose is the same : BETTER CODE.

That's all.

Answer 7

I wrote about this in my book about peer code review.

In common language there is no difference at all, and this is the answer I would typically give.

In academic literature, an "inspection" generally means a full-document review with heavyweight process. The process will involve some if not all of the Fagan Inspection parts including a "Reading" phase (reviewers by themselves) and an "Inspection" phase (everyone together in a room). Each person has a role (e.g. Moderator, Author, Reader, Reviewer) with certain goals.

Having gotten some training in the Fagan Inspection myself, I can tell you that the Fagan method in particular is strict, even requiring code print-outs for example.

In practice, few people still perform these types of "inspections" due to the obvious time constraints. I have found that people who are successful with "review" tend towards lightweight techniques.

Lightweight "code review" techniques include just looking over someone's shoulder, automatically sending emails after code is checked into version control, pair programming, and using one of the tool specifically made for code review including my company's Code Collaborator, Atlassian's Crucible, and the open source CodeStriker and Review Board.

Although I personally believe that lightweight techniques are 80-90% as effective as formal inspections (see the book for data and studies), it is undeinable that they take a small fraction of the time (because a 2-hour meeting with 4 people is a person-day of time). So even if you think they're only half as effective, it's still a much smarter use of time.