5 simple tips for Junior Developers to get fewer comments on your PRs

Halfway through my education to become a Web Developer (Software Engineer, Front End Developer, Programmer — call it what you will), I joined a small tech startup for an internship.

I was going through my tasks fast and fairly efficient, I was learning plenty and feeling pretty good about myself most of the time — or at least until I had to request a code review. The developer who was supervising me had high standards, and sometimes I felt as if I could never do things right and get my code merged without multiple comments.

At the time it felt frustrating to me being a young and new developer rushing to be “done”. Now, as a more experienced programmer, when I review code written by junior developers, I understand my internship mentor way better. Sometimes as developers we are so focused on (and excited about) writing code that actually works that it’s easy to forget about everything else.

So here are a few things I learned not only from having my code ruthlessly… reviewed, but also from reviewing other developers’ pull requests (PRs).

1. Read your own code

I know, I know, this sounds obvious. But it took me a while to get into this practice. After you raise your PR, just open the “files” tab and imagine that you are now a code reviewer, not the developer who wrote it. Scroll through all the lines and be critical. Did you forget something? Does something look like it should be refactored? Trust me, you are almost always guaranteed to spot something yourself before others do.

2. Clean up the mess

Things that you should remove before giving your code to reviewers should include:

• console statements,
• “todo” comments — generally try to get rid of as many comments as possible. If you gave your functions and variables proper names, most of the time you don’t really need that comment explaining what the function does. Nobody will read them anyway and they will just create mess in the codebase,
• redundant functions that are not used anymore after your refactoring,
• redundant variables that are not used anymore after your refactoring,
• redundant imports of modules you are not using anymore,
• multiple lines importing different modules from the same file, e.g.:

import { myFunction } from “./util.js”;

import { mySecondFunction } from “./util.js”;

should be rewritten into

import { myFunction, mySecondFunction } from “./util.js”;

3. Reduce whatever you can

There are different ways of deciding, whether the size of your PR is reasonable, or is it too big for a reviewer to stay focused. The general rules mention usually max 400 lines. I think that is already a lot and personally, unless there is a really good reason, I do not bother to review PRs with more than 10 files (yes, I look at files, not lines).

I remember once somebody had requested me to review a PR consisting of 35 files. He pushed a whole feature, multiple pages of functionality (sic!), all in one go. In order to review his code, I had to arrange a demo meeting with that developer, and the presentation plus his explanation took more than half an hour, after which I still had to review the actual code. Think about what a waste of time it is for both the reviewer and the code owner!

The “smaller is better” rule applies also to the functions you write. While you are self-reviewing, before giving your code to those merciless harpies also known as your teammates, try to refactor your functions into ~5-liners. Give them meaningful names too. If you are in doubt whether it is possible — yes, it is. Every time you have to write a condition, you have an opportunity to extract the code from that condition into a separate function.

So out of “spaghetti code” like this:

you can extract extra five functions that are way more readable:

The code above might seem longer and as if it takes too much time to write. It is however easier to review and to maintain in the future when the changes come, and since we all work in agile — the changes will come.

4. Name things like you mean it

As a person who wrote that code, you know what “r” is and why it has to be added to “t” in order to return a “g” through the function “rToG”. But a reviewer won’t know that. So unless the scope of a variable is only one line, like e.g.:

const longName = allNames.find((n) => n.length > 1);

make sure to give it a name that will be understandable for other developers.

Abbreviating long names into the letter-long ones is a trend of the past. Now we have advanced compilers and transpilers to make sure for us, that our code will not take up too much space, so you can relax and change that “r” into “response” and that “t” into “blogTitle”.

The same advice applies to function names. If your function is retrieving data, prefix it with “get”. If it’s assigning data somewhere, prefix it with “set”. If you have a boolean, prefix it with “is”, e.g. “isPageActive”. The more you explain through your names — the fewer questions your reviewers will have.

5. Follow the organisation standards

I am writing this advice as the last one not only because it’s the most obvious one, but also because sadly, not every organisation has well-documented coding standards. However if yours does, it’s important to follow them.

Some companies provide their developers with settings for linters, some have software (like e.g. Sonar Cube) checking code quality. Make sure to follow and oblige to whatever your organisation requires from you.

What are your experiences raising and/or review PRs? What do you pay attention to, when reviewing code? What helped you improve your own code? Let’s have a discussion in the comments!