Nice writeup! Two hints to get the most out of code reviews:
Take a look at the diff.
Before sending your code for review, take a look at the full diff outside your editor.
For example, do a compare vs base branch in GitHub. Make sure it's a split diff, not a unified one (latter is horrible to parse).
Looking at your change outside the editor gives you a real birds-view perspective. You'll notice misindents, missing comments. You'll feel the itch to polish it up.
Act on all instances of the comments.
Even if the reviewer commented on a specific instance of the problem (like having a too long method), go over your change and fix it at all relevant places (break other long methods too).
Note: don't go overboard, only apply this on your change, but not on unchanged parts of the touched files. Those cleanups should happen in separate changes that don't modify functionality.
Nice writeup! Two hints to get the most out of code reviews:
Take a look at the diff.
Before sending your code for review, take a look at the full diff outside your editor.
For example, do a
compare vs base branchin GitHub. Make sure it's a split diff, not a unified one (latter is horrible to parse).Looking at your change outside the editor gives you a real birds-view perspective. You'll notice misindents, missing comments. You'll feel the itch to polish it up.
Act on all instances of the comments.
Even if the reviewer commented on a specific instance of the problem (like having a too long method), go over your change and fix it at all relevant places (break other long methods too).
Note: don't go overboard, only apply this on your change, but not on unchanged parts of the touched files. Those cleanups should happen in separate changes that don't modify functionality.
Source: mindmap for my work-in-progress handbook Programming Without Anxiety.
Bonus: use my Stylus script to make code in github files-changed view vertically compact. HD code review experience!