Second is that they should be deployed judiciously: if you're making dozens of them on one PR then something is wrong either with the PR or with you. If it's you, then figure out which 2-5 or so (depending on the changeset size) are most important to you and let the other ones go. If it's the PR, then pulling the author aside and working with them to understand the codebase style, and helping them push a revised changset, is a better route than carpet-bombing their PR. (And you'll probably want to follow up that pairing beforehand for the next couple of PRs they do.)
Third is how to express them: the examples in the article are pretty good in this regard. Remember that these are optional improvements, and some of them can be subjective even if they're backed by common practice in the codebase. Be friendly rather than curt with your colleagues. And give some justification for your suggestion. If you can't come up with a good justification, it might be a sign that the comment isn't worth making.
On the receiving side, also try to take the comments in a friendly spirit. It's easy and natural to react negatively to any kind of comment on something you've worked on. But let that pass and don't make it part of your outward response. And most of all try to remember the suggestions reviewers make, so that they're not forever saying the same thing on your PRs. And if that does arise for some reason, it's again cause for a side conversation.
