Not everyone will need a checklist for code reviews, and not all code reviews will fit into your checklist. We accept that, and we have written about how some more senior developers sometimes even think they get in their way. They are a very good idea, however, if you haven't yet reached a comfort zone with your reviews.
A good checklist will keep you consistent. It will also prevent mistakes and omissions.
Here's our humble proposal, just to get you started:
Are all requirements met? 📋
Requirements are the basis for all development. Regardless of what the project you're working on is, and its scope, you will have a series of basic (and not so basic) requirements that the code must accomplish.
Check them, one by one.
Find the relevant code.
Review it.
Job done.
Are code conventions being followed? 🤝
Code conventions aren't bylaws, and they will change from project to project, and from language to language. They must be kept consistent throughout, otherwise, you can give rise to a whole ocean of troubles.
Whatever's been established for the project and language you're working with, it's your job while doing a code review, that everything is up to snuff. That ranges from things as trite as indentation to things as meaningful as comments.
Consistency is the key word.
Are magic values/scenarios accounted for? 🦄
What would you think if you saw the number 259200000 in the middle of a particularly important piece of code about dates (i.e. days and months, not romantic liaisons), with no explanation?
And that number is absolutely key for the way the function works?
You wouldn't be happy, would you? Well, that's the number of milliseconds in three days, and some people might immediately get it and others might not. Anything that is key for the inner workings of your code that isn't explained, is said to just "magically" work.
There's no magic in development. Make sure everything is clear. Which leads us to:
Is the code easy to read? 🤓
Remember: you don't know who is going to be doing maintenance on the code base your team is working on. It may be you, or not. And even if it is you, it's going to be the future you. We can promise you right now that you will not remember why that wonderfully clever function you've just written down works.
Everything needs to be readable. As readable as you can possibly make it.
Does it have good test coverage? ✅
As much as the codebase as possible should be covered when running your tests. If the percentage isn't high enough, then you probably need to consider changing the battery of tests you're running.
Tests aren't technically a part of code reviews, but they definitely go hand in hand as two of the most effective practices to ensure code quality.
Is there no unused code? 💤
Pretty self-explanatory, right? If the code is unused, it shouldn't be there. No good can come of it. Only mistakes.
Did you enjoy our little checklist? Did we miss something? Is there a key step to your reviewing process that you feel should be on everyone's list?
Make sure to drop us a line on Twitter (@codereviewpad) and let us know.
Top comments (0)