Effective code reviews: 9 tips from a skeptic

I knew the theory. A code review helps:

• Find bugs
• Ensure code readability and maintainability
• Spread code knowledge throughout the team
• Faster new team members
• Show everyone new approaches to solving problems.

Or, it's just a waste of time. At least that was my first impression of the code review.

I was a recently released rookie developing plugins for a software company in London.
After some time, I had to provide blocks of identical or similar code. They should have been viewed by an unhappy guy (“He is the best,” said my manager. Not a single good deed ... ( goes unpunished ) However, each review came back with something new. It seemed useless picky and random process.
Even worse, code inspections dragged on for days, if not weeks. When I received the code back, I could hardly remember how I wrote it. This was not the fault of that guy. He asked the senior level developer, but got me. He was sick of the mistakes made by inexperienced developers, and code reviews were a way to get rid of this frustration.
Add to this the time lost on branch synchronization, switching between contexts ... I was not a fan of this, there were none of them in the rest of the team, as it turned out.
Jumping a few years ahead, I find myself agreeing with a tweet by Jeff Atwood:

“Collegial code reviews are more you can do to improve your code.”

When I evaluate the past years, I understand that the non-code reviews were bad. The code review was done poorly. And man, we did it badly.
I recognized this in my own skin. And, of course, understanding does not come instantly. Only after a while I realized that the code review saved me from more than awkward, breaking assembly changes! But after I worked in other places, I gained experience in various and better ways of working. This gave me the opportunity to directly see the benefits of code reviews that I had not previously recognized. Therefore, now I consider myself a corrected skeptic.
So you can avoid such pains: check out our video and then read tips that will bring you closer to effective code reviews.

9 review tips

For all:

• Browse only the most important, let the tools do the rest.
  You don’t have to argue about formatting and code style. There are many tools that consistently solve these issues. It is important that the code is correct, understandable, and maintained. Of course, style and formatting are part of this, but you have to let the tools test these things.
• Everyone should look at the code.
  Some people are better at it than others. A more experienced person may well discover more errors, and this is important. But more important is the support of a positive attitude towards code verification in general, and this will allow us to avoid the “We are against them” attitude, or the fact that for a code review it is burdensome for someone.
• View all code.
  No code is too short or too simple. If you look at everything, then nothing will be missed. Moreover, this makes the review part of the process, a habit, not a requirement.
• Learn a positive attitude
  This is important for both reviewers and code authors. A code review is not the time to get all fives and influence your coding skills.
  You do not have to take a defensive position. Approach the review with a positive attitude of constructive criticism, and you can build confidence in this process.

For reviewers:

• The code review should be frequent and short sessions.
  The effectiveness of your reviews decreases after about an hour. So putting off a review to view them all in one huge session will not help anyone. Find the time during the day that matches your breaks - so as not to disrupt the flow and form a habit. Your colleagues will thank you for that. Waiting can be frustrating, and they can resolve issues faster while the code is still fresh in their heads.
• Saying “all is well” is normal.
  Don't be picky; you don’t need to look for a problem in every review.
• Use the checklist.
  Checklists for code review ensure consistency - they make sure that everyone keeps track of important and common errors.

For code authors:

• Code must be concise.
  After 200 lines of code, code performance is significantly reduced. By the time you look at 400 lines, they are almost meaningless.
• Provide context.
  Give links to any related tickets or specifications. There are tools for Review Kiln type code, that will help with this. Give short, but helpful commits and lots of comments in the code. This will help the reviewer and you will get fewer questions.

Register now for the Kiln Code Review Webinar

Join our next online webinar. It will help beginners learn the basics about code inspections in our product.
We will discuss:

• What is a code review
• Why use code review
• When to use it
• What to watch during the review
• Create Review
• Comments in the review and answers to them
• Work with existing reviews
• Code review process

To take a seat, register now .