Strides Interactive

Source control and Indirect Code ReviewFiled Under: Articles, Weekly Tuesday Dose of goodness

This week, I’ll talk about the experiences I have had with source controls and code review that is being done indirectly.

Apart from the obvious problems in software development (which can be sniffed out by various tools that check codes at different levels), there’s also a side of development that isn’t obvious.

That is - design flaws.

So, how does a source control help in sniffing out these design flaws? Let’s find out…

Before we begin, we need to have at least 3-4 items on our hands.

1) Source Control System
2) Diff Viewer
3) Source codes that has a previous version

My recommendations?

1) For source control, you can use Subversion 1.5 or 1.6 - download it at http://subversion.tigris.org/
2) For Diff Viewer, I’ll recommend WinMerge - download it at http://winmerge.org/
3) For source codes, of course, you should already be doing a project or something. Be if work related or personal.

For the first 2 items, they’re of couse free for download as well as free to use.

First of all, let’s start by asking -

Answer: Do you conduct any forms of code review?

If yes, do you do it manually, automatically or both ways?

Answer: Usually done manually.

We know the biggest difference between automated code review and manual/assisted code review is that automated code review does not and cannot understand your design, but it can find out bad coding practices that can be very hard to find by eye or warning level 4.

However, manual/assisted code reviews are important as well. Why? Let’s sidetrack a little. Why do software houses hire more and more developers from time to time? The biggest reason is because, these companies have money rolling in. How does these money roll in - by taking on projects. What does a project represent? Requirements!

So, where does requirements lead to? Design and tasks!

So what happens when designs are not adhered to and tasks are not properly done? The project is then considered to have failed due to inability to deliver on time or delivered on time but has more than 3-4 defects per million lines of codes.

With such stringent quality requirements, both automatic and assisted code review must be conducted. Let’s focus on assisted code review today.

Let’s begin with code review itself - what exactly is code review?

Based on: http://en.wiktionary.org/wiki/code_review

(software engineering) (uncountable) The practice of identifying and verifying the choice of algorithms, coding styles and compliance with the software design.
(software engineering) (countable) The act of performing code review on a particular piece of code.

What is software design? It’s the design of how logical components should work with each other. This includes high level framework talking to each other or as low level as how variables affect the outcome of other variables.

A high level design would be known as a workflow or dataflow.

A low level design would be better known as an algorithm.

Are both of them important? YES. This therefore explains why code review is important for software algorithm and design inspection.

Usually, when we perform code review, it’s with 1 reviewer, 1 author and 1 monitor. Who plays these roles depends on who’s the one doing the job. The author is usually played by the developer, the reviewer can be another developer, a senior developer or a project lead for example. The monitor will usually be someone who is senior or in a management position.

So now we’ve established its importance, where does source control come into the picture?

Based on what we’ve discussed earlier, this is also known as direct manual code review, or if there’re tools involved, it’d known as direct assisted code review.

A source control can come into play by perform self-code review. This is also known as indirect because it’s still a one-way code review with work done in the past (based on the source control).

Next, based on this type of code review, the developer can find out design flaws by themselves before checking in their final version in the repository. This is accomplished using a diff viewer, viewing the differences between the current version and 1 version before the current version in the source control.

This is a step that can be taken before the actual code review.

Once compilable, build-able and checked into the source repository, a formal code review can then take place.

The reviewer will then update (not revert or replace) his own source based on the source control’s version. Based on the code review requirements, he’ll highlight the source file (highlighted in red in SVN Subversion) and do a diff view. By then, a proper code review can easily be conduct and focused without having to point out technical flaws more than design flaws.

Diff View using Tortoise SVN

Here’s a picture of WinMerge with a single difference in the source codes. Note that this is a real difference based on the work done in StridesLib currently.