Code review questions: what should you be looking for?
Have you ever had your mind go blank when put on the spot? It’s a frustrating affliction — one that might strike when you’re asked to complete a code review. After the obvious questions, (i.e. ‘does it compile?’, and ‘does it behave as expected?’) your expertise decides to go on holiday.
So, where do you go next? What other code review questions might you need to ask?
To get you started, here are a few examples of the questions to ask yourself when conducting a code review.
Questions of readability
● How easy is it to understand?
Eagleson’s law: ‘Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.’
If you can’t understand the code easily now, the author will likely be in the same boat later down the line. So, make sure the code is understandable. For example, with consistent naming, useful comments, and so on.
● Does it follow your company’s coding standards?
If in doubt, refer to your company’s coding standards. Anyone from your team should be able to look at that code, understand it, and write in a similar way.
● Are there any repetitive lines of code or opportunities for useful abstraction?
Look for areas where an abstraction could make the code easier to read, or where the author has repeated themselves. Abstractions and removal of repetitive code both reduce the risk of errors later.
Questions of functionality
● Do all IF and ELSEIF conditionals have a conclusion?
As in, what happens if the conditional is not met? Make sure there’s a default case, or that every ‘IF’ and ‘ELSEIF’ conditional ends with an ELSE conclusion.
● Are there any TODOs?
TODOs are incredibly useful, but they can also act as a signal for future technical debt. This is because many of them can end up forgotten or buried in a sea of code.
If there are any TODOs, are they clear to find? Are any of them doable now?
Considering objectivity
● Are any of your objections based on subjective preferences?
Everyone has their own coding style and preferences. That is, there are many different ‘right answers’ in code. So, make sure your comments relate to a specific problem — and aren’t just reflecting your preferences and opinions.
● Would you have written it in the same way?
That said, there is a benefit to thinking about how you might have tackled a problem. If it’s different, consider why. Is your chosen way more efficient, or less? Have they done something you wouldn’t have? Code reviews are as much an opportunity for you to learn as they are for the code author. Take that opportunity.
Bonus: when giving your feedback
When sharing your findings with the author of the code you’ve reviewed, it’s important to keep it positive. Overly negative or accusatory comments could get dismissed as vindictive or nit-picky. When discussing flaws with the code, then, avoid ‘you’ and ‘your’. Instead, talk about the code. For example, ‘the code doesn’t comply with this coding standard’.
Code review questions can come in handy here too. Remember, a code review is as much a chance for learning as it is anything else. So, don’t be afraid to ask questions or for clarification. For example:
● Have you tried…?
● I don’t understand this section, can you explain…?
● Would it be better to…?
Code review questions
There are hundreds of things you might look for during a code review. These are a few examples of the questions you might ask.
Indeed, there are many more options out there. But hopefully, these questions give you a starting block to inspire your own considerations and stop your mind drawing a blank.
