I was recently asked to speak about best practices and guidelines for effective code reviews. In preparing for that presentation, I thought a lot about what works and what doesn’t, and why some teams seem to get a lot of use out of the code review process while others see it as a necessary evil or a hindrance in the way of pushing code.

Much has been said about specific ways to ensure useful code reviews, and most of it really is useful advice that you should go read and practice.

What’s more important, though, is that every member of your team understands what reviews are for. Reviews are not just for the benefit of the person whose code is being reviewed. They are a way for everyone involved in a project to understand how things are changing in other parts of the codebase. They ignite some of the most useful debates which end up leading to better design decisions in the long term. They give junior reviewers a chance to observe the kinds of things more skilled reviewers hone in on. They even lead to better naming, which is the second hardest problem in computer science and something you should worry about getting right.

Once it becomes clear that all of these are goals of the code review process, guidelines and rules are no longer necessary. Just use common sense.