Code Review Checklist

Vinu Vasudev
3 min readMay 7, 2022

Having a checklist is an essential part of a development team. It will help us to streamline our code review and helps to focus on our priorities.
These are the things I consider while reviewing a new code or pull request

1. Readability

The readability of code is highly underrated in the industry. Most people push for code documentation and inline comments, which are defintely good. But readable code is much better for maintaining a reliable and scalable codebase.
These are the key factor whcih I consider while checking the readability of code.

Code indentation

Though wrong code intends don’t affect the functionality of a program but it does impact person reading and maintaining the code. Even for an expert it is difficult to identify the boundaries of functions, loops, and conditions if not intended properly.
A proper indentation is the first thing we can do to ensure our code is readable and clear to the concerned party.

Naming Conventions

The way we name our functions and variables has far-reaching effects. The names we choose for functions, variables, and classes should be self-explanatory. In some cases a self-explanatory name will be too long, in such cases, we can use shorthands.
For getting a list of users we can name the function getUsers() or getUserList() which is far better than random names like getData or some gibberish. In the same way, the response of the above function can be assigned to a readable variable like userList or users which is far better than the trending "newArray".

There are a lot of indentation styles available, famous are K&R style, OTBS, 1TBS, Stroustrup and Allman style.

Code Comments

There is a popular saying,

“Code is for the compiler, while comments are for the coder”
We cannot make our codebase self-explanatory all the time. Comments come into the picture when codes can’t explain themselves. I personally prefer to write code comments only if the code is not self-explanatory enough.

2. Performance

On seeing a code always look for a simpler solution, even one iteration less in the codebase will make the code perform better when you look at the bigger picture. Basically, we need to check if the code runs for too long and if there is any simpler solution that's worth implementing.

Key factors that one should consider in the performance area,

  1. Performance requirement, whether any performance SLA is part of the requirement
  2. Looking at external calls, calls outside the service are costly
    1. Database calls
    2. Unnecessary network calls
  3. Looking for possible memory leaks
  4. Make sure code closes connections and streams when not needed
  5. Check for possible race conditions

3. Reusability

Code reuse is the approach of using existing code for new features and functions. DRY principle, “Don’t Repeat Yourself” helps to reduce code duplication. The principle is simple, if there is a need to do something more than once, move that code to a function and reuse it. This code abstraction helps to functions make the code reusable and scalable. This will help in debugging also, as we don't have to fix a bug at no two places.

4. Maintainability

Following best practices is the key to high maintainability. Codebases should be loosely coupled and highly cohesive. The terms might look opposing, these two work together to create highly maintainable and scalable applications.

Code should be implemented in such a way that unrelated units are loosely coupled and there should be a high cohesion between related units. If we don't follow this best practise we will be moving towards high coupling and low cohesion which will result in excessive dependencies and increased vulnerability to bugs as bug in one unit will affect all the dependent units. Following SOLID principle will help in achieveing this good practise.
SOLID principle is nothing but a union of 5 design principles.

  1. Single responsibility principle
  2. Open Closed principle
  3. Liskov principle
  4. Interface segregation principle
  5. Dependency inversion principle

5. Unit Test

Looking at test coverage and finding the edge cases that or accounted for will be tricky and might take time, but it’s worth it. I dont want to explain how unit test test helps to maintain code quality. The benefits are widely known and still tends to look away from it.
Following TDD is good approach to make unit tests mandatory

--

--