Image, originally published by Josh McDonald. License: Creative Commons 2.0

Much has been said about the importance of code reviews. Jeff Atwood says: peer code reviews are the single biggest thing you can do to improve your code.

Steve McConnell in his book Code Complete says:

… software testing alone has limited effectiveness – the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent. Case studies of review results have been impressive...

Here's another blog post by Kevin Burke where he shows how code reviews beat testing for enhancing the quality of code.

However, code reviews are not just for improving code quality; code reviews are also a great tool for learning.

Even though most of us know the usefulness of code reviews,  not everyone is fortunate enough to be part of a team that does them regularly. Or we may be working solo on a project and there is no one to do code reviews with. What can a developer do in such circumstances? Is it possible for a person to review their own code? I think it is. Even though a self review may not be as effective as a peer review, it is still better than no review. In this article I'll discuss 5 things you can do to review your own code.

Static analysis tools
Static analyzers are the first line of defense against bad code. Static analyzers examine source code for certain well known anti-patterns.  These tools will point out obvious mistakes which you should not have made. Once you get past this stage, you can be sure that your code is clean of the most obviously known anti-patterns. The only problem with using static analysis tools is that they may raise a lot of irrelevant issues. However, this problem can be countered by configuring them to flag only those issues that you are interested in.

Using static code analyzers is a great way to do a self review.  Here's a fairly comprehensive list of static analysis tools for various languages.

Comment your code the next day
This one may come as a surprise to you. After all, how can commenting code (the next day) serve as a way to review it. But this technique has actually come from my personal experience. Several years back I as working on a project where we had some downtime and were waiting for feedback from the client. With nothing else to do, I sat down to comment code I had written a few weeks back. Interestingly, I was able to look at the code objectively as I started commenting it and revealed several places where the code could have been better. Since them I have used this technique on code I had written down just a few days back to code that was written a day back. Every time I have had the same experience: I was able to review the code as if I were reviewing someone else's code and was able to spot places where it could be improved.

Try it out if you don't believe me. Don't comment your code as you write it. Instead comment it after a couple of days or the next day. You will be surprised at how effective this simple practice is as a method of self code reviews.

Apply the single responsibility principle
Very often, bad and unmaintainable code is the result of violating this principle. It happens when a chunk of code does more than one thing (like your mobile phone doubling up as a nose hair trimmer :-)). A chunk of code can be anything: a method, a class, a package, or a module.

The single responsibility principle is probably the most important design maxim after the DRY (Don't Repeat Yourself) principle. But unfortunately it is also the source of several code maintainability issues because it isn't followed as ardently as it should.

Static analyzers will not catch places in code that violate this principle. But at the same time, spotting such issues doesn't require a peer review. It's not too difficult to do it ourselves. You can easily spot it when you comment your code. If you often find yourself using the word "and" while documenting what your code does, then you can be sure that you are not honoring this important principle. Be mindful of this principle when you do your self code reviews and you will have eliminated a great deal of issues at the beginning itself.

Follow test first development
Adopting test first development forces you to write code and design your API's in a way that allows them to be tested with unit tests.

When we don't follow test first development, we often write code which cannot be tested at all. It happens when the code instantiates dependencies that cannot be properly created in a test environment. Code which cannot be covered by automated test suites can break anytime without anyone even knowing about it.

Adopting test first development is the simplest way to ensure that such code never gets written. Another advantage of writing tests first, is that it makes you think of all sorts of boundary conditions and error conditions before the production code is actually written. In a way this is similar to reviewing your code at the inception itself.

Put small chunks of code on a code review site
As I said at the beginning - a self review is better than no review, but it doesn't match what we can achieve in a peer review. Even those who do not have the privilege of peer review, can still get their code reviewed in a limited manner. There are several code review sites (codereview.stackexchange.com being one of them) where you can post small snippets of code and request reviews from the development community.

However, you will have to be very careful about what you post out there. You should never post proprietary code, because not only is it unethical, but it will also violate any non disclosure agreements you may have signed with your company or client. Being careless about such things can get you into serious trouble.

The best candidates for posting on online review sites are small code snippets that do generic things. That way you are not exposing any specific proprietary code but can still take advantage of having peers review the generic parts of what you write.

However, because this is so important, I am going to repeat it again. If you are writing code for someone else, make sure you get every chunk of code you plan to publish for an online review, approved by someone who has the authority to do so.