The key to these types of interactions is to make them impersonal. In the case of coding standards (which don't have to do with logic/implementation) try to get all of them enforced by either an automated linter/formatter or a written style guide. Then you're not saying "I think you should ..." it's either a CI error or a link from you to the style guide. There shouldn't be any argument on these points.

Another thing to do is to make sure the person you're reviewing understands how much you care about each comment. I like to prefix things I don't care about with "nit:" or "optional:" to signal that I noticed something and wanted to share my thoughts but I don't think it's a blocking issue.

Finally make sure you're being humble and friendly. If you're worried that a certain block of code might confuse a future reader, say that it confused you! There's a huge emotional difference between "this is confusing, please refactor" vs. "This was hard for me to understand at first, could you consider refactoring or adding a comment to make this easier for future readers?". By showing your own struggles, you can bring more empathy into the conversation.

----

While I'm here ... I should plug that I am the creator of https://codeapprove.com which is a tool designed to help you review code like a pro. Code review is all about reaching distributed consensus, and CodeApprove helps you get there faster.