Code Review Guidelines

Code Review is an important step in the development process. It helps not only to catch bugs early on, it also helps with sharing both domain/technical knowledge and to enforce coding standards.

Culture

It all starts with culture, code review should be viewed as a collaborative effort to deliver good quality product and not a process to judge the developer’s work or vice versa.

Reviewer is equally responsible for any bugs as much as the developer, so due diligence should be exercised during the review.

Demo

Developer should prove either using unit tests or in by deploying it in local that the requirement(s) in the ticket are met. If there is no such demo, the changes should not be approved

Checklist

Are new unit tests added?

Are error conditions properly handled?

• null checks
• data type checks
• corner scenarios
• are errors logged with enough detail?

Logs

• are log levels used correctly? debug vs info vs error
• are there enough logs to help troubleshoot after deployment

Clean code

• do new variables have descriptive names? Will a new person able to understand what the variable is for?
• do new functions have meaningful names?
• are the new classes small? If the changes are in an existing class, are the changes making the class too big? This may be an opportunity to create a new class instead of adding to the existing one

New function(s)

• do they have meaningful names?
• will the caller know what the expect when it calls the function
• are they small? can they be broken down into smaller functions?
• are the parameter names meaningful?
• are they unit testable?

Is the code format good?

Complexity — too many nested blocks? opportunity to break it down?

Performance

• can the code be more efficient?
• are unnecessary objects being created?

Is there any code duplication

Best Practices

• Do not send more than 200 LOC for review.
• The review should happen as early as possible and the developer should be willing to make any change asked for. If the review happens late, everyone will be under pressure to push the change without proper review and feedback loop.
• There can be multiple reviews for the same change: an initial review can be on the draft version of the code and another review when the code is production ready.