Skip to main content

Make your code review requests count


The value in PRs (or code reviews in general) is more than just ensuring good code is pushed into the main-line branch. There's more to a PR in my opinion. This includes

Learning from others
Sharing learning, understanding, and the architecture of your system
Someone doing a cod review. Source: WikiMedia Commons


Have you ever received a code review request where someone has ran a tool over the file and changed formatting, spacing, or convention? Or where someone wished to create a new line after every dot, or change brackets? There’s nothing wrong with these types of requests in isolation.

What is wrong is when the request is sent with valuable code changes. That is, a combination of formatting changes and valuable code are pushed together. In these scenarios, the formatting change is often much more than the valuable code change.

The attention of the reviewer now must be shared between actual code change and noisy, unnecessary formatting changes. Therefore, important things such as new architecture and concepts may be missed or subconsciously ignored. As well as picking up on legitimate issues with the code being reviewed.

I suggest that you don’t undervalue your requests for code review. If you really want to make formatting changes, submit one request with the higher quality code, and submit another with the formatting changes.


Comments

Popular posts from this blog

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.


from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

Context and agile practices

At times we have competing responsibilities - ship code or don't ship it because of a small edge case bug; put pressure on our team or make the business happy; coach our friends or write code.

This is a normal part of our everyday professional lives, and it's important to strike a balance that will help us in the future, but also deliver in the short-term.