# Tips to Be a Good Code Reviewer

Reviewing other people’s code is an important skill as a software engineer. Here are some tips to be a good code reviewer.

General Rule

1. Generally speaking, we should prioritise PR over your task if you are assigned as a reviewer. Any lingering pull requests are blockers to the team.
2. Be explicit about nit (e.g. Nit: variable name might be better with aaaa).
3. Be explicit about the change suggestion (e.g. if makes it easier for the developer to understand, add the proposed code).
4. Do not use obscure acronyms.
5. Make sure to include the detailed reasons for your suggested change.
6. Make sure to spend time with the reviewee to do pair programming if they are struggling with the change you suggested. Reviewer cannot just throw a comment. They have to take responsibility to help reviewee. I don’t want us to make excuse of not finding time. PR should be our priority. I have seen a reviewer just throwing comments and reviewee has no idea about how to change.
7. Don’t hesitate to ask questions if something is not clear.

What you should look for

• Legibility – Legible code is more reusable, bug-free, and future-proof.
• Consistency – This makes a code base easier to read and understand, helps prevent bugs, and facilitates collaboration between regular and new/infrequent developers.
• Code Quality – Improve internal code quality and maintainability (readability, uniformity, understandability)
• Looking at the requirements – Are all cases fully implemented?
• Style guidelines – Does the new code conform to existing guidelines?
• Finding defects – Such as performance problems, security vulnerabilities or obvious logic errors in the code?
• Learning/Knowledge transfer – Help in transferring knowledge about the codebase, solution approaches, expectations regarding quality, etc; both to the reviewers as well as to the author.
• Mutual Responsibility – Increase a sense of collective code ownership and solidarity.

What you shouldn’t look for

• Formatting Suggestions (Linting) – That is the job of the linters. If the linters are not picking up the linting error, consider to update the linting rules.
• Quibble over details If there is an unresolvable disagreement between reviewer and reviewee just escalate it to (tech lead/ manager).
• Making it personal – Be professional in your criticism.
• Vague generalities – Be explicit about your intention.
• Finding better solutions that change the design completely – Solution design should be completed and thoroughly reviewed prior to development.