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
References
1.
Zimmerman, J. Code Review from the Command Line Jake Zimmerman. at https://blog.jez.io/cli-code-review/ (2018).