# Code Review

When I ask that other people review my code, it’s an opportunity for me to teach them about the change I’ve just made. When I review someone else’s code, it’s to learn something from them.

• Jake Zimmerman1

## Commenting

Paul Slaughter developed a set of conventions for leaving comments2. In short:

<label> [decorations]: <subject>

[discussion]


Where label is:

Label Description
praise Praises highlight something positive. Try to leave at least one of these comments per review. Do not leave false praise (which can actually be damaging). Do look for something to sincerely praise.
nitpick Nitpicks are small, trivial, but necessary changes. Distinguishing nitpick comments significantly helps direct the reader’s attention to comments requiring more involvement.
suggestion Suggestions propose improvements to the current subject. It’s important to be explicit and clear on what is being suggested and why it is an improvement. Consider using patches and the blocking or non-blocking decorations to further communicate your intent.
issue Issues highlight specific problems with the subject under review. These problems can be user-facing or behind the scenes. It is strongly recommended to pair this comment with a suggestion. If you are not sure if a problem exists or not, consider leaving a question.
question Questions are appropriate if you have a potential concern but are not quite sure if it’s relevant or not. Asking the author for clarification or investigation can lead to a quick resolution.
thought Thoughts represent an idea that popped up from reviewing. These comments are non-blocking by nature, but they are extremely valuable and can lead to more focused initiatives and mentoring opportunities.
chore Chores are simple tasks that must be done before the subject can be “officially” accepted. Usually, these comments reference some common process. Try to leave a link to the process description so that the reader knows how to resolve the chore.

Where decorations might be:

Decoration Description
(non-blocking) A comment with this decoration should not prevent the subject under review from being accepted. This is helpful for organizations that consider comments blocking by default.
(blocking) A comment with this decoration should prevent the subject under review from being accepted, until it is resolved. This is helpful for organizations that consider comments non-blocking by default.
(if-minor) This decoration gives some freedom to the author that they should resolve the comment only if the changes ends up being minor or trivial.

## Command Line Code Review

Determine Base Branch One time set this alias, which requires gh the github command line tool and jq. ~/.gitconfig

[alias]
basebranch = !gh pr view --json baseRefName -q .baseRefName


Checkout code to review:

git fetch; git checkout <branch> OR gh pr checkout <pr-number>

Set base branch variable:

export MERGE_BASE=git basebranch


Open code diff in (neo)vim

~/.gitconfig

[alias]
review = !nvim -p $(git files) +\"tabdo Gdiff$REVIEW_BASE\" +\"let g:gitgutter_diff_base = '$REVIEW_BASE'\" reviewone = !nvim -p +\"tabdo Gdiff$REVIEW_BASE\" +\"let g:gitgutter_diff_base = '\$REVIEW_BASE'\"


Note: This is slow to start. It runs the diff of each file in neovim, possibly a difference in CLI calls