In my last post Code Reviews are for wimps I discussed some of the processes and tools of a great code review.  I thought I would share how I do a code review from top to bottom to provide value.  I don’t wish to treat code reviews as a rubber stamp to the next stage.  This requires diligence, discipline and practice.  Here are some 5 questions that could be on your team checklist. 

Question 1:  Does it meet the customers requirements?

If no other question is asked make sure this one is.  This requires effort on your part as a code reviewer.  It demands looking at more than just the code changes that were implemented by the developer.

  • Look at the requirements document/story/feature.  If you don’t have one, you have another problem that code reviews cannot solve.
  • Review the test cases and understand what has been tested.
  • Read the developer notes on the feature.  If none are present, note this in the code review and encourage the developer.

Stop here if you don’t meet this requirement and send it back to the developer.

Question 2:  Does it compile and are tests passing?

It should be expected behavior to build and compile the source with the changes implemented.  However, one more than one occasion I have received source that doesn’t build or compile for whatever reason.  If this happens in your review it might be time for a special Training Program (It works on My Machine).

Look at the list of tests that were created for these code changes.  Just a quick skim will let you know the type of coverage that the tests have and may highlight areas where more time in the code review will be appropriate.

Question 3:  Do you see any logical errors?

Focus on the flow of the code.  Do you see:

  • Possibilities for infinite loops?
  • Out of Range conditions?
  • Computational issues?
  • True/False evaluations?
  • Variable assignments issues?

Start from these in your team and add as appropriate.

Question 4:  Do you see any code structure issues?

These can be a little more subjective.  Adherence to good policies in this area can drastically improve your code base.

  • Are your methods doing too much?  Look at the length of the methods, cyclomatic complexity and other measurements as part of your review.
  • Is the code in the right namespace?
  • Has the code already been implemented somewhere else?  Sometimes this requires a SME of the system.
  • Are there refactoring opportunities that could take place to improve code readability and maintainability.

Question 5:  Are you following team coding standards?

Many teams have standards that should be published and acknowledged before any developer starts coding.  I rate these lower on the scale in the code review process, because they don’t directly affect the code in most cases. Here are some coding standards that I have seen across teams (for good or bad):

  • begin fields with underscores for readability
  • Add comment header to every method
  • Place the copyright at the top of every file
  • Indent with spaces instead of tabs


These questions are a starting point in creating a good code review checklist.  Refine Code Reviews to become a best practice in your organization.

What questions would you add?