[robotpony]

Most of these points all relate to having empathy for the developer and being kind, and focusing on the point of code reviews (which is to improve quality and reduce ongoing costs).

Example:

> Unhelpful behavior: overwhelming with an avalanche of comments

Code that isn't consistent to standards absolutely needs to be fixed. And while it's a lot of work to keep code up to standard, the author is correct that the nitpicking approach is unproductive.

A better approach is to review code like this, see that it falls short, and suggest realistic (and in turn kind) ways to improve things. Picking at each missed space is clearly counter productive, and there are more standard and helpful solutions.

Why not suggest adding:

- lint tools - requiring code meets standards - auto formatting tools

I don't think things like minutia fit in code reviews either, but the small stuff does matter.

I feel the same about the other suggestions, they can be boiled down to: don't be an ass; be kind; be constructive. Just imagine that you're reviewing your own code from 5 years ago.

[Domenic_S]

She did suggest those things further down the article:

> Helpful Behavior: automate what can be

> Reviewing issues that can be caught by linters, git hooks, or automated tests are unhelpful because they often result in an avalanche of comments and come off as nitpicking. People are not particularly good at catching these issues, hence why automation tools exist.