I have some experience in setting code review standards at the places where I've worked, and it's something I've thought about a lot (maybe too much). Anyway, I agree with pretty much everything the author wrote.
This is a slight tangent, but one possibly unintuitive rule that I always like to add is to avoid asking "why" questions, like
> Why is `x` a single-precision float?
It's unintuitive because as the reviewer you may well want to understand that "why," but the problem is that this phrasing is secretly a personal question, not technical. (By the way, my number one rule of code review is never make it personal. It's about the code, not the coder.) Note that you can't get around this by replacing the "why" with a synonym, like "what is the reason for...," which is just more words and not much better.
The solution to this as a reviewer is to recurse into your own thought process and ask yourself why you want to ask the "why" question, and just say that instead. In practical terms, what this usually means is to just say what you think may be the better alternative and why, which makes it a concrete technical choice that can be discussed.
> I think `x` should be double-precision because [...]. What do you think?
(And if you actually are just curious about the "why" and not implying a coding error, say that explicitly.)
I have some experience in setting code review standards at the places where I've worked, and it's something I've thought about a lot (maybe too much). Anyway, I agree with pretty much everything the author wrote.
This is a slight tangent, but one possibly unintuitive rule that I always like to add is to avoid asking "why" questions, like
> Why is `x` a single-precision float?
It's unintuitive because as the reviewer you may well want to understand that "why," but the problem is that this phrasing is secretly a personal question, not technical. (By the way, my number one rule of code review is never make it personal. It's about the code, not the coder.) Note that you can't get around this by replacing the "why" with a synonym, like "what is the reason for...," which is just more words and not much better.
The solution to this as a reviewer is to recurse into your own thought process and ask yourself why you want to ask the "why" question, and just say that instead. In practical terms, what this usually means is to just say what you think may be the better alternative and why, which makes it a concrete technical choice that can be discussed.
> I think `x` should be double-precision because [...]. What do you think?
(And if you actually are just curious about the "why" and not implying a coding error, say that explicitly.)