How I learned to do Code Reviews

Code reviews, something that I think all organizations should do, however that is not the case. If you are one of those organizations, and looking to start, I would like to offer up the way that I have recently learned. Code reviews don't have to be painful and can generally be a pretty simple, repeatable process. With that lets get started.


The purpose of the gernal walk through is to get an idea of changes that have happened to your code base. Here you will probably skim the code on first pass. Does the code look to be in the correct location or should it be moved to another more fitting home. Is this changing existing code or does it work in tandem with existing code and if so does it make sense. The purpose of this is a first pass or first glance kind of action.

  • Purpose
    • Why was this code written.
    • Was it needed.
  • Existing Code
    • Is this changing existing code
    • Does it work with existing code
  • New Code place
    • Is this in the right place


In this part of the code review we run things like linters, test suite, any kind of type checkers. The point of this part of the review is to let the robots do some of the heavy lifting and see what errors that it might catch. Did it pass 10/10 on linting? What if it scores a 9.95 out of 10, are you ok with that? This can also help with the complexity (McCabe) scoring below by looking at functions and testing how complex they are. Running our unit test suite helps make sure that we have our code tested as best as possible.

  • Linting
  • Type Checking
  • Tests


Now we go into the laser focus here. At this point we are looking at the code and scrutinizing it for complexity, we are looking to see if anything could be refactored more because it might be a little complex. We are also wanting to look at the variable names and the function names and any constants. Does the code tell me a story and can I follow that story. What about tests? Did the publisher of the software provide new tests or update old tests to reflect code changes? Did they tests not only valid data but maybe some unexpected data. This is the section that looks for all of that. Lastly, we want to actually run the code because that will be the true test.

  • Focus on the code functions
  • Complexity (McCabe)
  • Internal naming
  • Read new / old tests
  • Run actual code

As you can see these steps are really easy, straightfoward and very much repeatable. This is how my company reviews our code and it has really helped with limiting the number of bugs that get introduced into our system. I hope that if you are starting out with your code review, that these steps can also help you.