My opinion on what makes a good Code Review.

Grant Riordan - May 8 '22 - - Dev Community

Why do we do Code Reviews?

Code review is simply what it says on the tin. It is the opportunity for other developers to look at your code commit and review it.

Code reviews are one of the key elements to the development lifecycle. Without them poor or buggy code could make it's way into UAT and slow down the testing / release process.

My tips

Word comments carefully

Remember that the person's code you're reviewing has probably put a lot of effort into this work, and they haven't deliberately made mistakes, especially those easy to miss spelling mistakes etc.

Try not to be too soul crushing when leaving comments.

Don't be so forceful with comments or suggestions. For example rather than saying

Change this variable name

Say something like:

Perhaps this could be worded to a more descriptive variable name.

This way the suggestion for improvement is made, but in a way that makes the coder feel they still have a say / matter is open for discussion.

Be clear and concise.

Be straight to the point and clear about what you want changed or are advising. Don't waffle on, beating around the bush simply state the What and Why.

Most git systems these days allow you to click on the line you wish to be changed , and add a comment so it's much simpler to specify the exact line of code you want changed.

Hosting providers such as GitHub have a "suggestion" feature which allows you to add a code suggestion directly into the comment, which can instantly be accepted and committed from within the PR.

Multiple changes of the same kind.

Rather than commenting every single occurrence of the problem (this can be overwhelming for coders. Simply add one comment and explain the issue occurs throughout multiple files, and suggest finding all occurrences and updating, e.g a spelling mistake, or repeated code.

Not everyone codes like you

Remember that not everyone codes the same and certainly doesn't always code the way you do. This doesn't mean they are wrong, and nor does it mean you're way is best.

Always take a step back and think about the key elements of code review.

  • Does the code follow your team's coding guidelines

  • Does the code meet its objective / acceptance criteria.

  • Is the code legible and easy to understand what it's doing without the need for heavy comments / documentation. (This one for me is one of the most important, as I'm a huge fan of descriptive method and variable names.

  • Does the code need any refactoring, considering security, performance or simply ease of reading.

  • Does the code follow simple design patterns / principles e.g single responsibility, abstraction, encapsulation etc. If not make suggestions on how this can be achieved or perhaps teach those not familiar with it what it means and the benefits.

These are some of my tips I hope they've been helpful.

Feel free to discuss your tips and methods of code review in the comments.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .