Code review is a software quality assurance process in which software’s source code is analyzed manually by a team member or by using an automated code review tool. The main motive of the whole process is to achieve great quality software product, good maintainable/readable source code. Code review is an essential process that every software company must follow, so we analysed the best practices that must be followed during the code reviewing process.
Why is a Code Review required?
Code reviewing is not about going through lines and finding mistake. It is kind of a support extended to the juniors/ the person who has written the code. This process will bring the best out of them. Whenever someone tells you to review the code, do it and share your honest genuine review, so that they get a better understanding about incorrect coding practices. This insight into correct coding practices helps the programmer to write better code. A checklist of sorts helps the process of code review.
When you do a Code Review?
Ideally one must start reviewing the written code from the early phases of implementation. If you’ve written more than 500 lines of code, it will become difficult for reviewers to give proper feedback. So to prevent this - frequent code reviews becomes a crucial step.
How to do a Code Review?
Prepare check list and explain this to the team
Prepare a checklist and share this with the team. This sets the tone and sets the proper expectations on the code quality. All reviewers will have the prepared checklist with them so that they won’t miss anything while reviewing the code.
Review for no more than an hour at a time
It is a known fact that human efficiency decreases if they work continuously more than an hour. So it is not good practice to do a code review continuously for more than an hour. Ideally short periods of 45 mins of review helps in optimal code review practice.
Automate to Save Time and human error
Automating some of the review points using good static analyzer tools like lint, SonarQube, CodeSonar etc. will help us to save time and minimize human error.
Adopt positive work culture
Positive work culture increases productivity and efficiency. Everyone in the team has to take this code review process in a positive way and work to achieve their goal.
How to prepare a checklist
Your checklist should have the following points.
Architecture / Design
Split problems into multiple layers and tiers as per requirements such as presentation, business and data layer.
Do not place multiple responsibilities into a single class or function. Instead refactor them into separate classes and functions.
When adding new functionality or when existing code should not be modified. New functionality should be overwritten in new classes and functions.
Code duplication :
Move similar code into separate classes or functions.
Shape/File Hierarchy offences :
There should be proper hierarchy for the code/files structure. When we look into the overall structure in file manager or IDE, it should be properly organised and should look similar across the project.
Potential bugs :
Look for the potential human error which leads to potential bugs.
Whether all corner conditions are handled correctly or not?
Do all loops terminate properly?
Error handling :
Look for possible error cases.
Are errors handled explicitly and gracefully wherever necessary?
If there’s some business logic or algorithm in the code, is it using an efficient implementation?
For example, iterating over a list of objects to find specific objects based on some criteria.
Method names :
Methods are perhaps the most common element of your programming interface, so you should take particular care in how you name them.
Variable names :
Expressive variable names make it easier to understand code when we have to revisit it later.
Function length :
Ideal function should be less than 20–50 lines.
Class length :
Classes should be under about 100–300 lines. It’s likely that large classes can be split into separate objects, which makes it easier to understand what the class is supposed to do.
File length :
Around 1000–1500 lines of code is about the most we should have in one file. Anything above that is a good sign that it should be split into multiple files.
For complex functions or lists of arguments, you need to have docstrings about what function does and the importance of each argument.
Commented code :
Always clear commented code to avoid unnecessary confusions in future.
Number of method arguments:
For the methods and functions, do they have 3 or fewer arguments? Greater than 3 is probably a sign that it could be grouped in using class or structures.
Need to ask questions about the code while reviewing?
Then it is a sign of more comments needed or simplifying your code?
Test coverage :
Test for new features implemented.
Are the tests thoughtful?
Do they cover all success/failure conditions?
Are they readable?
How big are the tests?
Are they efficient/slow?
Number of Mocks :
Test cases with more than three mocks should be refactored. The code should have a refactor into multiple functions.
Meets requirements :
Usually as part of the end of a review, take a look at the requirements of the story, task, or bug which the PR was filed against. If it doesn’t meet one of the criteria, it’s better to question it back before it goes to QA.
All team members should have proper common understanding about the overall process of code review from beginning to end during the project execution. Team discussing and understanding each other’s position is far more effective in practice than people telling others where they’re wrong. It is all about learning from each other’s code and making the product super efficient and maintainable.
Take the next steps by setting up a code review checklist and by implementing the industry’s code review best practices. You need to make necessary improvements to this checklist regularly for your team, product and company, so don’t be late to make changes, and always keep an open mind.
CodeCraft Technologies has been recognized as a Top 30 Android App Development Agencies in 2021 by DesignRush.