Code Review

Jake Zimmerman ¹

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.

Commenting

Paul Slaughter developed a set of conventions for leaving comments². 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

1. Zimmerman, J. Code Review from the Command Line – Jake Zimmerman. (2018).

2. Slaughter, P. Conventional Comments.