Conventional Comments
Esteban Campos / August 31, 2020
6 min read • ––– views
TL;DR#
The importance of leaving meaningful comments that can be applied immediately without a second reading.
Code review#
The primary purpose of code review is to make sure that the overall code health of the code base is improving over time. In order to accomplish this, a series of trade-offs have to be balanced. A key point here is that there is no such thing as "perfect" code—there is only better code. Reviewers should not require the author to polish every tiny piece before granting approval. Rather, the reviewer should balance out the need to make forward progress compared to the importance of the changes they are suggesting. Instead of seeking perfection, what a reviewer should seek is continuous improvement.
A pull request, intends to improves the maintainability, readability, and understandability of the system and it shouldn't be delayed for days or weeks because it isn't "perfect."
A secondary purpose is teaching developers something new about a language, a framework, or general software design principles. It's always fine to leave comments that help a developer learn something new. Sharing knowledge is part of improving the code health of a system over time.
Conventional Comments#
Comments like this are not helpful:
@miso
Can you improve the wording
By simply prefixing the comment with a label, the intention is clear and the tone dramatically changes.
@miso
Can you improve the wording
@miso
This is not worded correctly.
Labels also prompt the reviewer to give more actionable comments.
@miso
This is not worded correctly.
Can we change this to match the wording of the marketing page?
Labeling comments saves hours of undercommunication and misunderstandings. They are also parseable by machines!
Examples#
@daisy
Let's avoid using this specific function…
If we reference much of a function marked “Deprecated”, it is almost certain to disagree with us, sooner or later.
@jungle
These buttons should be red, but let's handle this in a follow-up.
Format#
Adhering to a consistent format improves reader's expectations and machine readability. The format proposed is:
<label> [decorations]: <subject>
[discussion]
- label - This is a single label that signifies what kind of comment is being left.
- subject - This is the main message of the comment.
- decorations (optional) - These are extra decorating labels for the comment. They are surrounded by parentheses and comma-separated.
- discussion (optional) - This contains supporting statements, context, reasoning, and anything else to help communicate the “why” and “next steps” for resolving the comment.
For example:
@kinoko
At this point, does it matter which thread has won?
Maybe to prevent a race condition we should keep looping until they've all won?
Can be automatically parsed into:
{
"label": "question",
"subject": "At this point, does it matter which thread has won?",
"decorations": ["non-blocking"],
"discussion": "Maybe to prevent a race condition we should keep looping until they've all won?"
}
Labels#
Some suggested labels:
| 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 are specific requests to improve the subject under review. It is assumed that we all want to do what's best, so these comments are never dismissed as “mere suggestions”, but are taken seriously. |
| issue | Issues represent user-facing problems. If possible, it's great to follow this kind of comment with a suggestion. |
| 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. |
Decorations#
Decorations give additional context for a comment. They help further classify comments which have the same label (for example, a security suggestion as opposed to a test suggestion).
@marcy
I'm a bit concerned that we are implementing our own DOM purifying function here…
Could we consider using the framework instead?
@ichigo
It looks like we're missing some unit test coverage that the cat disappears completely.
Decorations may be specific to each organization. The recommended is establishing a minimal set of decorations (leaving room for discretion) with no ambiguity.
Possible decorations include:
| 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. |
More Examples#
@jungle
Run the prettier command. There are some tweaks that need to be done.
@marcy
Awesome! You did a really job good!