Code Reviews, a Checklist

Reviewing code from fellow developers should be considered a best practice. While its main goal is to make sure your teammate didn’t lose track of what a good software developer should do, it can also help the reviewer extend his knowledge of a project and get inspired by other’s code.

5 Golden Rules

Things to have in mind/check when you review code include these 5 golden rules:

  1. The code compiles on the reviewer’s environment without warnings and tests are not broken.
  2. The new code implements the bug fix/feature it was supposed to.
  3. The code remains DRY.
  4. Things are kept small and simple, with a clear separation of concerns: “each class should do only one thing, and do that one thing well”. If you don’t get what the new code is doing, something’s wrong.
  5. The new code is tested.

How to review code?

My team is using GitFlow on our own Git servers (i mean “no GitHub”, so no “pull request”). My way to actually review code is the following:

A note about testing

Reviewing code that doesn’t include tests can be disappointing for a reviewer and adding some tests after an implementation feels like cheating. Here is a quote from Daniel Eggert - from the excellent objc.io - that both reviewers and reviewees should have in mind when reviewing/developing:

Tests should help us speed up development and make things more fun. [...] Generally, if you find something difficult to test, that’s a hint that your design may be broken and that you should refactor some of it. [...] You’ll get diminishing returns as you add more tests. First and foremost, add simple tests. Branch into more sophisticated territory as you start to feel comfortable with it.

Other resources discuss the subject:

Conclusion

I’ll try to add some examples and additions to this page as I process code reviews in the future. Again, feel free to get in touch to provide some feedback and as this page is open source and available on GitHub, pull requests are welcome. I’ll review them with a great pleasure.