Provide honest criticism, but avoid being nasty. In this piece, we’ll discuss some of the most typical problems encountered by young programmers during code reviews.
1. Not reading the code
This may seem like an obvious first priority, but there is a good rationale for placing it here. In reality, you didn’t study the script. You obviously just glanced over it. There are no noticeable problems with the syntax. That seems to be working out well, right? Wrong. In other words, decipher the script. Check out the commit remark. Learn as much as you can from the available materials. Make an effort to grasp the author’s intended meaning. Does it add up and make sense? Don’t skim; peruse it line by line. Reading the code is a prerequisite to providing constructive criticism.
2. Not testing the code
Although it may not always be possible, one could effectively “execute” the code in the PR, you should. Whenever you evaluate code for a user interface or any other component that modifies the front end, you must be able to see the effects of those modifications. Only by actually executing the algorithm can this be accomplished. You haven’t truly tested the code if they only show you pictures or pasted test results. Take the initiative and grab the fork, then build and test the code. Check that it operates properly. Tell this person to get a life if they’re upset that you didn’t take their advice for it and to go have another cup of espresso or something.
3. Not leaving comments
The only way for the author to receive comments and criticism is if they are written down. Find a point of contention. Speak. Seen anything interesting that tickles your fancy? Talk. You may comment on the script as you study it and provide comments. There is always going to be something to find wrong with a piece of code, no matter how well written it is. Spend some time writing well-considered remarks regarding the code.
4. Not confirming tests
It’s just routine upkeep for the code review process. Please ensure all automated tests are performed before presenting your work for a new evaluation. If the testing isn’t automated, you’ll have to do it by hand. Verify that any further scheduled tests are operating normally. Be certain the script is properly linted. Inspect the automatic linters if available. Unless they are, you should lint it yourself or request the outcome. This is the author’s responsibility, however, the critic should examine their work. Checks that are meant to happen during code reviews should be visually inspected.
5. Not asking questions
Perhaps you have a query regarding a decision they made. Gain insight into a design principle? Inquire whether they have considered using a different syntax. Make use of the review by asking questions. Enquire as to the rationale for the use of this particular label rather than any other. Inquire more as to why they decided on this particular library. Don’t be shy about asking questions, particularly if you’re confused.
