Code review, or you can call it Peer review, is an activity for Software Quality assurance, which one or several people involve to check parts of the code.
This article is sort of a guide on what to look for in a code review, so the code base can have better quality, reviewers and the author can learn from it.
Functionality
The first thing to look for in a code review is the functionality. For a feature, reviewers can look for edge cases, potential problems, to make sure no obvious bugs are visible just by looking at the code.
You can have a validation on the changes. Try the feature, or run a demo to see if there is any bugs for performance issues.
Complexity
Have you ever seen a function or a component that is too complex to even understand it in a quick look ? Even though the code can run fine, but reviewers can’t understand it quick enough might be a logic problem. There would be potential bugs if a piece of code is too complex too, and debug it will be even more painful.
We can call it Over-engineering, when a piece of code has things that isn’t presently needed by the system, engineers should be focused on things that they need to do at the moment first, not problems that might be needed to solve in the future.
Naming
Did the variables name are good ? Did functions name are good ? Did classes name are good ? A good name is long enough to fully communicate what the code is or does, without being so long that it becomes hard to read.
Comments
In my opinion, comments are commonly bad. So whenever I see comments while doing code review, I often have a lot of question for the existence of it. I wrote an article about it, right here
In short, did the developer write clear comments without errors ? Are all of the comments actually necessary? If the code isn’t clear enough to explain itself, then the code should be made simpler.
There are some exceptions (regular expressions and complex algorithms often benefit greatly from comments that explain what they’re doing, for example) but mostly comments are for information that the code itself can’t possibly contain, like the reasoning behind a decision.
Styling
Coding conventions are a set of guidelines for a specific programming language with recommended programming style and practice.
Reviewers need to make sure the changes follows the appropriate style guides.
Tests
Unless the changes are hot fixes, reviewers should ask for unit or integration or end-to-end tests.
Reviewers need to make sure the tests are useful, clear, and correct.
Don’t forget that tests are also code, we should look for all of the things above when review tests
Compliments
If the code looks good, don’t be shy, we can tell the author about it. This can encourage the developers to continue doing good stuffs
Top comments (0)