Peer PR (Pull Request) reviews are an important part of a developer's everyday schedule. Whenever we are assigned a PR for peer code review many times we aren't exactly sure what to check.

So here are some tips and suggestions about what I check while reviewing a PR that is assigned to me in NO particular order 😜

• Typo in variable/function names

  It's pretty common to have typographical errors while naming a funtion (see what I did there 😉) or a variable. So we need to make sure the spellings are always correct as sometimes when we want to find a method by its name, we can't as we haven't used the correct spellings while writing the method.

• Duplicate Code

  This is also a common mistake that we developers do sometimes like defining a variable twice, rewriting a new method when the exact same method is already present in the code.

• Unused injections and variables

  There is a lot of code that we initially feel we will require but while doing the code cleanup a developer can miss removing some service injections, variables that are unused.

• Code indentation

  I     don't   know       if it'  s just me      but     I find     it  annoying           (aren't these uneven spaces annoying to you too?) to review un-indentated (not sure if that's an actual word 😛) code. A well indentated code improves code redability while reviewing a PR and should be made mandatory in all languages like it is in Python (Yes, Python uses indentation to highlight the blocks of code)

• Unoptimsed Queries/ Multiple DB calls

  While reviewing API code, do check if we can optimize the queries further, and also it is advisable to minimize DB calls if we are fetching the same data multiple times in the same method.

• Unintentional changes

  Many times we add or delete code in files we didn't really need to work on. Try to notify the dev about it before approving the PR.

• Communicate

  When the code can't communicate with you, meaning when you don't get the logic behind why a certain condition or a library is used then don't hesitate to ask. Communicate with your peer and only approve the PR when you are fully satisfied with the code.

• Appreciate

  Whenever you find a line/block/architecture of the code worth appreciating then do tell the developer about it. It motives them to do even better.

• Be Kind

  Lastly don't use PR reviews to show any kind of hatred/anger towards your peers. Be kind while telling mistakes and don't sound arrogant. In other words, give a suggestion, not an order. After all, having a bug/problem-free code is good for everyone. Also, I would advise the submitter to not feel bad or demotivated if their PR has more comments. Use reviews for your own growth and try not to repeat the same mistakes again.

There are many other things that I see in a PR but they are more domain/situation-specific (like implementing the correct logic as per requirement).

Hope you got to learn something new today 😃

Also, buy me a coffee, book or a pizza by clicking the image above if you like what I am doing and want to support me. 😅

What practices do you follow while reviewing? Do let me know in the comments below.