Reviewing a piece of code: What exactly should you look out for?

Reviewing a piece of code: What exactly should you look out for?

After personally reviewing some codes this year, I paused at a point to ask myself what more I need to pay attention to when next I review someone's code. After a few times of reflection and study, I will like to share with you my learnings and opinions.

Code reviews are the quality control checkpoints where a developer's code faces its fiercest critics—who are fellow developers. It's the place where bugs are unearthed, best practices are enforced, and the collective wisdom of the team is pooled to make your code not just functional but truly exceptional.

So, what exactly should you look out for in a code review? Buckle up, fellow developer, because in this article, we're going to embark on a journey to uncover the secrets of effective code reviews. We'll explore the dos and don'ts, the best practices, and the hidden gems that can turn your code review process into a symphony of collaboration and improvement.

Ready to become a code review virtuoso? Let's dive in and demystify the art of reviewing code.

  1. Design: You need to check that the code agrees with the existing design of your codebase. Does the newly introduced code follow standard design patterns? e.g. DRY principle, employs SOLID principle and also take into consideration the OOP concepts where necessary. You might also want to check that implementations that can be separated into new functions are not chunked in an existing function.

  2. Functionality: Here you can check if the intended behaviour of the application is what the code exactly presents. Here you can think of edge cases, breaking points of the new code

  3. Complexity: You need to check if classes and functions are not complex. This is so that developers who would encounter the codebase in the future find it really easy to understand.

  4. Tests: If the change is a new feature and no tests are written, you might want to request for unit test, most especially. Other types of test like integration or end-to-end can be requested if required.

  5. Naming: Naming is very important. It is one element that adds to the readability of code as well as makes it possible for others to easily understand your code if properly done. While reviewing codes, check that class names, function names and variable names correctly and succinctly depict what it is intended for.

Your entire aim as a reviewer is to focus on the improved health of the codebase you are maintaining.

Ensure that the codebase stays maintainable overtime and new changes come in. Pay attention to the fact that the coding pattern/style remains the same.

Lastly keep in mind that personal preferences should not be a yardstick to approving a PR. Do not enforce your personal preferences on others. You can however mentor with your comments, stating what you think and noting that it not so important to implement the change or that in future, another approach could be explored.

Also, remember there is no perfect code what exists is better code.

See you in the next post!