How To Do A Good Code Review
Code reviews are powerful means to improve the code quality, establish best practices and to spread knowledge. In this post, I will provide a quick guide on how to do code reviews the right way.
Prior to the review, you should follow this tips that will guide you towards an effective peer code review
- Build and Test: This ensures stability. And doing automated checks first will cut down on errors and save codeline. Make sure that the code does what is expected.
- Review fewer than 400 lines of code at a time: If you try to review too many lines of code at once, you’re less likely to find defects.
- Take your time: Code reviews in reasonable quantity, at a slower pace for a limited amount of time, results in the most effective code review.
- Do not review for more than 60 minutes at a time: Never review for longer than 60 minutes at a time. Performance and attention-to-detail tend to drop off after that point.
- Give Feedback That Helps, Not Hurts: Try to be constructive in your feedback, rather than critical.
- Use checklists: It’s very likely that each person on your team makes the same 10 mistakes over and over. Omissions in particular are the hardest defects to find because it’s difficult to review something that isn’t there. Checklists are the most effective way to eliminate frequently made errors and to combat the challenges of omission finding. Code review checklist also provide team members with clear expectations for each type of review and can be helpful to track for reporting and process improvement purposes.
Design
The most important thing to cover in a review is the overall design of the CL. Do the interactions of various pieces of code in the CL make sense? Does this change belong in your codebase, or in a library? Does it integrate well with the rest of your system? Is now a good time to add this functionality?
Identifies The Main Bad Smells
If it stinks, change it. — Grandma Beck, discussing child-rearing philosophy
- Names: One of the things we must be clear about here is that we write code for people, not for machines. Once we are clear about that, we must learn to use descriptive names. Naming is one of the two hard things in programming. A good name can save hours of puzzled incomprehension in the future.
- Comments: The only perfect comment is the comment you found a way not to write. There are some exceptions (regular expressions and complex algorithms often benefit greatly from comments that explain what they’re doing, for example) but mostly comments are for information that the code itself can’t possibly contain, like the reasoning behind a decision.
- Duplicate Code: If you see the same code structure in more than one place, you can be sure that your program will be better if you find the away to unify them.
- Long functions: The longer a function is, the more difficult it is to understand.
- Large Class: When a class is trying to do too much, it regularly shows up too many fields.
Tests
A suite of tests is a powerful bug detector that decapitates the time it takes to find bugs.
In this part, you must make sure that the tests cover the added features and also have a clean tests.
What actually makes clean test? So, to be honest I’m not an expert implementing test (I’m on my way) but the thing that makes test clean is readability is more important in unit test than it is in production code. What makes test readable? The same thing that makes all code readable; clarity, simplicity, and density of expression.
Good things
If you see something nice in the CL, tell the developer, especially when the addressed one of your comments greatly. Code reviews often just focus on mistakes, but they should offer encouragement and appreciation for good practices, as well, it’s sometimes even more valuable, in terms of mentoring, to tell a developer what they did right than to tell them what they did wrong.
Summary
- Follow the tips on how to do a good code review.
- The code is well-designed.
- Any code smells (Comments are clear and useful, good naming, etc.).
- The code isn’t more complex than it needs to be.
- Tests are well-designed.
