I'm working on a project solo and have to maintain my own code. Usually code review should be done by someone other than the author so the reviewer can look at the code with the fresh eyes. I don't have such luxury. What practices can I employ to more effectively review my own code?
Answer: Checklist & Refresh (7 Votes)
It seems the common sentiment is that self-review is not effective. I disagree, and I think self-review can catch a lot of issues if done thoroughly.
Here are tips from my few years of experience:
- Have a rough checklist handy. These are things you want to flag while you read your code.
- Take your code review offline. It might sound wasteful, but take printouts that you can annotate and flip back-and-forth, or the digital equivalent of nicely highlighted pdfs synced to an iPad which is then taken offline. Go away from your desk, so that all you do is review your code distraction-free.
- Do it early in the morning, rather than the end of a working day. Fresh pair of eyes is better. In fact, it might help to have been away from the code a day before reviewing it afresh.
Just an FYI—these guidelines were part of recommendations made by Oracle a few years ago when I was working there, where the aim was to catch bugs "upstream" before the code went into testing. It helped a lot, although it was considered a boring job by a lot of developers.
Answer: Delay & Document (11 Votes)
First, set your code aside for as long as practical. Work on something else, some other piece of code. Even after a day, you will be amazed at what you will find.
Second, document your code. Many programmers hate to document their code, but make yourself sit down and write out documentation, how to use the code and how it works. By looking at your code in a different way, you will find mistakes.
It has been said that true mastery of a subject is the ability to teach it to someone else. With documentation you are trying to teach someone else your code.
Answer: Rubber Duck Review (10 Votes)
Transform the Rubber Duck Debugging technique into a code review technique.
The concept works wonders by putting you into a proper mindset for working through code as if it were new.
Of course, you can also use online tools like Code Review, SourceMonitor and klocwork.
Answer: Go Historical & Static (9 Votes)
The Personal Software Process technique for reviews might be useful, although it relies on having historical data about your work and quality of products.
You start with historical data about your work products, specifically the number and types of defects. There are various methods of classifying defects. You can develop your own, but the idea is that you need to be able to tell what mistakes you are making along the way.
Once you know what kinds of mistakes you make, you can develop a checklist that you can use during a review. This checklist would cover the top mistakes that you make that you think can best be caught in a review (as opposed to using some other tool). Every time you review a work product, use the checklist and look for those mistakes or errors, document them, and fix them. Periodically revise this checklist from time to time to make sure you are focusing on real, relevant problems in your code.
I would also recommend using tool support when it makes sense. Static analysis tools can help find some defects, and some even support style checking to enforce consistency and good code style. (This page offers some explanations of the difference between static code analysis and code review.) Using an IDE with code completion and syntax highlighting can also help you prevent or detect some problems before you click "build". Unit tests can cover logic problems. And if your project is sufficiently large or complex, continuous integration can combine all of these into a regularly-run process and produce nice reports for you.
Answer: Print & Check (2 Votes)
I usually print out all my code and sit down in a quiet environment and read through it, I find a lot of typos, issues, and things to refactor by doing that. It's a good self-check that I think everyone should do.
Think you know the best way to review your own code or disagree with the opinions expressed above? Leave your answer in the comments or bring it to the original post at Stack Exchange.
reader comments
13