if you want to enforce higher standards than your colleagues, you have to put in most of the work to reach those standards. For instance, if you think a section of a code needs unit tests, maybe write some of the tests yourself or at least suggest how to.

also be modest, and make sure to frame your standards as cooperating to improve the company’s code, not competing to show you’re a better programmer

the ultimate goal is to make your high standards more of an asset (“he’s improving the code”) then a burden (“he’s criticizing us and making us do more work”)

High code standards or specific preferences? Are your comments more like, "If this receives two requests at once it will result in a race condition" or more of the "you used tabs but I like spaces" sort?

Imposing preferences on others via the mantle of "best practices" is a great way to annoy them.

I'm not sure how well it works exactly, but when I'm advocating for more rigor or error-checking or other high standards, I try to include justification for why changes to the project under consideration need to be held to this higher standard.

Have some conversations to build consensus with your team about what standards the codebase should be held to at this phase in its lifecycle, and when that decision should be revisited as the project matures and evolves.

It's fine to personally have high standards, but it's important to keep those distinct from the actual needs of the current development work.

For a given standard X like "always check errors" or whatever "Does this change maintain property X of the code?" is a very different question from "Is it worth maintaining property X in our codebase today".

Justifying that a change you advocate for is better is not enough; you also need to reach consensus on that improvement being worth the cost in time, complexity, maintenance, etc.

Also, don't try to revisit that consensus for small matters. Having consensus about what you're collectively aiming for, and people feeling confident that they're aiming at a stable target, is itself extremely important, and is worth trading off a bit of code quality for.

Something else I find really helpful for building credibility in your proposals being well-calibrated instead of universally "do better" is to look for opportunities to change your mind, to be persuaded by someone's argument, and for opportunities to say "This is great as-is; no need for complication here" or "Thanks for keeping this simple". You might consider aiming for "good taste and well-calibrated standards" as a replacement for "high standards".

Help people feel confident that you will advocate for lower standards when appropriate, and they'll believe you way more when you advocate that higher standards are worth it in a specific situation.

Comment on the code review but follow up privately and offer to pair.

It’s extra work but it shows the contributor that you’re not just out to poke holes and make extra work, it shows you actually care about their development and progression as an engineer

It might help to have some rationale or at least anecdotes.

The people nobody(tm) likes are the ones that insist on things without knowing why and/or without any relevant experience. They read it in a blog, or someone told them that's better, Google does it, cargo cult etc.

Start by assuming your coworkers have their reasons why they do something, not because their standards are lower. Maybe it's not worthwhile to spend time on making something a little more perfect when there's other more valuable things to invest your time in.

On the other hand, it is possible that your peers truly have lower standards, less experience, and don't understand what they're doing. Unfortunately there's no easy solution to that. It's possible that by being the annoying guy that always nitpicks you will be able to drive some improvement, but it'll take its toll on you. As others said, lead by example works somewhat. The problem though is that sometimes the "why" in software engineering only happens after many years.

I'll also second the idea of doing your code review with those people as a discussion vs. an offline process where you leave comments that can be interpreted in different ways.

Try this; 1. every PR review call out one neat thing you _really like_ and maybe ask how they figured that out 2. Be explicit in the dichotomy between "recommendations/nits" and "you shouldn't merge this". Weight things toward the former. Have a style guide for the latter things and be very conscious of when someone is violating the actual style guide or just your own biases. If you really have high "standards" write them down... Otherwise they are just whims, not really standards.

Pick your battles. Try to identify cases where at the end of the day, it doesn't matter if the code is not "the best TM".

Also don't hesitate to tag your comments as "nitpicks".

Try and organise a workshop to set some common coding standards. Having a commonly understood standard for good is an excellent way to start the process.