Have you ever considered whom do you review code for?
- Author, of the PR?
- Project, you are working on?
- Firm, you work in?
- 💰, since it is part of your job?
We should, in my opinion, review PRs for our coworkers and, more importantly, future coworkers who may be responsible for maintaining the code after we are gone. We all know, code is written once and then maintained indefinitely. As a result, the review process becomes more critical.
Reviewer is equally responsible for unreadable and unmaintainable code.
We should review PRs to ensure that our colleagues finish their work (of maintaining the code under review, in the near future) and return home or logoff on time.
Saving someone’s time is the best thing to do and one should be proud of it.
But understand that reviewing code entails an investment of your time. You can't save someone's time unless you put in your own.
Reviewing code in itself is a skill. Code reviews have become one of my favourite and most important topics of conversation during interviews. Nonetheless, I believe you are not obligated to review every PR, just as you are not obligated to save someone's time. But if you do then better do it right.
We won't discuss best practises for the code review process. There are plenty of posts that explain it. Instead let's discuss things one should not do while reviewing code.
- Your comments should always convey to the author that your intentions are to improve the code rather than to question his talent and expertise.
- Avoid unclear comments.
- Make sure the discussion doesn’t turn into debate. This is the worst thing to happen. There are 99% chances that your review comment might trigger this debate.
- Avoid pointless comments. No review comments are better than pointless comments.
- Finally, watch your tone in comments.
Best of luck in your efforts to make yourself proud by reviewing PRs and saving someone's valuable time. The time that could be better spent doing something more meaningful than staring at and cursing the dreadful piece of code.