Coding Notes
Code Review
Three tips when submitting code review:
Keep the amount of code being reviewed as minimal as possible. Takes a lot of time and harder to capture bugs. Reduce the lines of being reviewed in the pull request. Ideal PR is <100 lines of code.
Leave a good description. You want to give very detailed comments on the PR on what is being solved. For example, including images (e.g. web applications). In the code, part of the “diff” isn’t related to the main logic in the PR but was necessary in the PR, it’s good to leave a good comment in the description as to why this was included or what’s the relation of this piece of code was changed in the PR.
Tips when leaving comments to a pull request: over communicate as much as possible; write very clear comments. If you happen to disagree with the change, mention you do not but are ok with the change if they believe this is necessary (trust) “use your judgement”.
Feel free to ask for clarity on the code changes so the person who sent the PR understands your feelings about it.
Establish a criteria with the team for when to approve/disapprove the PR. It’s a bad feeling when the code reviewer provides small comments and doesn’t approve the PR. If you don’t have standards, then you don’t know the intentions of the person reviewing the code. Provide reason as to why the PR was rejected.
Know when to take things offline and not in the PR and wasting time with huge written paragraphs.