Code review. Some hints that help me do a better code review.
Just some words of introduction. When I was starting to do code review, of course, I wasn’t an experienced dev, and also I didn’t have any experience doing code reviews. Currently, after a few years, I look back and think that maybe these hints will help you to review the code better, understand more, save more time, or just make sure that other devs are doing the same :). And don’t forget - these are just hints that won’t replace your experience. Let’s start.
I sincerely hope they will help.
1. First of all — coding conventions.
It doesn’t matter how big or small your environment is (group of dev, team, project, company, etс.), it’s crucial to have coding conventions, at least a few, why? I think it will be enough to refer to the wiki page that describes it better than I could. And I’ll just add that it’s important to have them because of junior devs. It will help juniors to be much more confident doing code reviews. Of course, it still won’t be as valuable but at least it will help experienced devs remember the conventions, cause they often forget them…
Don’t worry junior devs, the value of your code reviews will increase over time :)
2. Do not impose your own style of writing code.
As you know, every developer has their own style of writing code. It is important to separate coding conventions and the way the developer likes to write code. Why? Because no one wishes to change anything in their own style if it’s not necessary (perhaps this is obvious). Let’s consider the simplest example just to convey the essence.
So if your favorite way of writing a constructor is a second or third way but while the code review you see the first one, would it be correct to comment on the constructor? And say that his/her way writing constructor is not optimal, best, etc.? Of course, you can and can even give him a lot of arguments why your approach is better than his/her one. And maybe after your arguments and some discussion time, the dev will start using a new way of writing the constructor. Yes, you have won, have imposed your own style. But was it worth it? I think it is much better to use the first hint I mentioned. If you are sufficiently convinced of your approach — just make a coding convention out of it. After that, You won’t have to impose your own style of writing code (and possibly feel uncomfortable) and explain to other devs again and again all about the optimality of your approach.
I know that creating a new coding convention can be expensive, but it’s definitely worth it.
3. Review the code like a “Senior”.
- Remember about coding conventions. (1)
- Don’t impose your own style of writing code. (2)
- Don’t be afraid to ask about everything that looks strange or you don’t understand.
Each question will help you to expand your horizons/borders. Of course, if you get answers to your questions ;). - Don’t tell/comment that code is wrong, better ask him/her — “why is the code correct”?
There’s usually a reason why the code is written like so. And also, don’t forget that there is always a chance that you are wrong about something. - If you don’t wanna ask, but still say/comment that the code is wrong, then say/write a solution that you would use.
The last point doesn’t need to be explained :P.
4. Self-code review.
It’s my favorite one. It doesn’t apply to the code review that you do for other devs but do for yourself. It is really hard for me to overestimate self-code review. Cause the more I use it, the more it benefits me. So, this code review you do for yourself before passing it on to anyone else allows you to:
- avoid silly mistakes, especially when there are a lot of changes and it took you a long time.
- think it over again and possibly make better decisions.
- recall the places you wanted to change but left to do it later. This is the perfect time to do that.
- finally, stop and ask yourself — didn’t I forget something? Have I done everything that needs to be done to achieve my goal/objective? I’ve actually forgotten something countless times, and I still do sometimes.
And the last thing I would add here is that we all do reviews throughout our lives to almost everything we do. Even for this article, I did a “self-article review” and used the above-mentioned points. Isn’t that curious?
BTW you are reviewing my article :).
If you have questions like:
- Why do I even need to do this?
- Is it really so important that you even wrote an article about code review?
Or this article was somehow useful to you, just let me know and maybe I’ll write another one about the importance and value of the code review. Cause I have something on my mind I want to share with you :).
