Code reviews are an effective way to improve code quality, create best practices, and disseminate information. In this post, I will provide a quick instruction on how to conduct proper code reviews.
Prior to the review, you should follow these 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: Every member of your team is quite likely to commit the same ten mistakes over and over. Omissions, in particular, are the most difficult faults to detect because it is difficult to assess something that does not exist. Checklists are the most efficient technique to avoid common errors and overcome the difficulties of omission detection. Code review checklists also give team members with clear expectations for each sort of review, which can be useful for reporting and process development.
Design
The overall design of the CL is the most significant aspect to discuss in a review. Do the interactions between the CL's various bits of code make sense? Is this update appropriate for your codebase or a library? Is it compatible with the rest of your system? Is now a suitable time to implement this feature?
It 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 hardest things in programming. A good name can save hours of puzzled incomprehension in the future.
- Comments: The only ideal comment is the one you avoid writing. Regular expressions and sophisticated algorithms, for example, can benefit enormously from comments that clarify what they're doing), but most comments are for information that the code itself cannot possibly include, such as the logic behind a choice.
- 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 a way to unify them.
- Long functions: The longer a function is, the more difficult it is to understand.
- When a class is trying to do too much, it regularly shows up in 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 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
Tell the developer if you spot something wonderful in the CL, especially if it directly addresses one of your remarks. Code reviews frequently focus solely on errors, but they should also encourage and reward good practices. In terms of mentorship, telling a developer what they did right is sometimes more beneficial than telling 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.
Post a Comment
Post a Comment