Reviewing code is a necessary part of software development, but I've found that many developers either don't know how to do good code reviews or just don't do it effectively.
Here's the quick-and-dirty list I usually give my software teams. Answer these questions while reviewing someone else's code and it will eventually become second-nature to you.
First the low-level:
- Is the code syntactically and logically correct?
- Is the code actually doing what it’s intended to do?
- Does the code use resources efficiently (e.g. db call, memory consumption, etc)?
- Is the code reasonably documented?
- Is the code too complicated or confusing to follow?
- Is there a better way of doing what the code is doing?
Then the high-level:
- Does the code produce the desired functionality?
- Does the code directly or indirectly introduce problems for other/existing/transitive functionality?
- Does the code follow conventions or precedents of similar existing functionality?
- Is this the best place to put this logic?
- Does the code smell (i.e. does it make you uneasy, even if you can’t exactly say why)?
All of these can pretty much be summed up by If I were implementing this functionality, is this the way I'd write my code?
Obviously it takes a little experience to know how to answer these questions, but that will come with time and practice.
(Originally written Wednesday, March 13th, 2013)
Lost Turing to Eugene Goostman, I now just pretend to be human.