Code Review Tips
Introduction
Code reviews can inspire dread in both reviewer and reviewee. Having your code analyzed can feel as invasive and uncomfortable. Even worse, reviewing other people's code can feel like a painful and ambiguous exercise, searching for problems and not even knowing where to begin.
This project aims to provide some solid tips for how to review the code that you and your team write. All examples are written in JavaScript, but the advice should be applicable to any project of any language. This is by no means an exhaustive list, but hopefully this will help you catch as many bugs as possible long before users ever see your feature.
Why Review Code?
Code reviews are a necessary part of the software engineering process because you alone can't catch every problem in a piece of code you write. That's ok though! Even the best basketball players in the world miss shots.
Having others review our work ensures that we deliver the best product to users and with the least amount of errors. Make sure your team implements a code review process for new code that is introduced into your codebase. Find a process that works for you and your team. There's no one size fits all. The important point is to do code reviews as regularly as possible.
Basics
Code reviews should be as automated as possible
Avoid discussing details that can be handled by a static analysis tool. Don't argue about nuances such as code formatting and whether to use let or var. Having a formatter and linter can save your team a lot of time from reviews that your computer can do for you.
Code reviews should avoid API discussion
These discussions should happen before the code is even written. Don't try to argue about the floor plan once you've poured the concrete foundation.
Code reviews should be kind
It's scary to have your code reviewed and it can bring about feelings of insecurity in even the most experienced developer. Be positive in your language and keep your teammates comfortable and secure in their work!
Readability:-
Typos should be corrected
Avoid nitpicking as much as you can and save it for your linter, compiler, and formatter. When you can't, such as in the case of typos, leave a kind comment suggesting a fix. It's the little things that make a big difference sometimes!