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.

Happy reviewing!

(Originally written Wednesday, March 13th, 2013)