Better solo code review
Solo code review is the first step to quality programming. Here’s a guide to keep it efficient and effective.
Solo code review should be the first step in delivering quality software. All code should be peer reviewed, of course, but the first step is your own review.
What’s the value proposition?
The bottom line: efficiency and good quality code. Nobody likes to check a half written document, and the same goes for programming. Under developed code, is never fun to peer review but more importantly, can be a disaster six months down the track when you’re trying to solve a problem.
Solo code reviews produce fewer lines of code, code with better logic, more readable code, more reliable code and better documentation.
How to do it
- Don’t use your editor. Use something that will show you the difference between what you had originally, and what your new view version looks like.
- Don’t try to remember your code, re-learn your code. If you can’t re-learn your code a few minutes after writing it, how will you achieve that in 6 months? How will your co-worker achieve it?
- Approach the review as though you’ve never seen the code before. Does the context make sense, and is the outcome clear?
- Look at every single change in your code. Could it be better? Could it be rewritten? Are you using language features appropriately? Does it meet your style guidelines?
When to do it
A great time to practice solo code review is once you’re finished. Once you’ve written your code, polished it, tests are passing and you consider it done. Then you should review your code; just before you check it in to revision control and ask for peer review.