If talking about logic and structure, that is something that is way harder to maintain consistently because we all think differently and might prefer different methodology or coding style for different things. There are many things that can be enforced, but project will never be 100% by standards if multiple developers work on it and that's ok. Something will sneak in eventually.
If you are talking about code style that can be enforced through linting tools and formatters, then you can for example add git precommit hooks that run those linting tools before each commit attempt. If there are linting errors, you just don't allow this code to be commited. This way you can automatically prevent errors from being commited into the code base and so you shouldn't have to worry about those during PR reviews because people won't even be able to commit those things you set as errors. You can also use tools to format code in this stage so all code will have consistent indentation and styling, which I find really valuable because it's easier to review and read code if it's formatted consistently (at least to me personally).
Using git hooks will also make it so that you don't have to enforce certain tools or IDEs for developers, so they can use whatever editor they want, your hooks will still run and do their job.
Of course, before that can work, you need to find linting tools you want to use and agree upon certain "standards" you want to enforce. For example, if doing JS/TS work, you will probably use ESLint and you just have to create your own ruleset or use some of the existing ones if you agree with them. Prettier can be used to format code, again if talking about JS/TS or even HTML and CSS in Prettier's case.
I think you will never be able to enforce things to achieve super clean code and that's fine. We sometimes get obsessed too much over "clean code" when many times we just need "code that works". Of course having a structured codebase helps a lot, but there is no need to get super stressed about it.
Sometimes you just don't have time and things need to get shipped so you just whip a quick fix for something and place that "TODO: Refactor this" comment that then stays in that code for 5 years without ever refactoring because it just works and that's the most important thing at the end of the day.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If talking about logic and structure, that is something that is way harder to maintain consistently because we all think differently and might prefer different methodology or coding style for different things. There are many things that can be enforced, but project will never be 100% by standards if multiple developers work on it and that's ok. Something will sneak in eventually.
If you are talking about code style that can be enforced through linting tools and formatters, then you can for example add git precommit hooks that run those linting tools before each commit attempt. If there are linting errors, you just don't allow this code to be commited. This way you can automatically prevent errors from being commited into the code base and so you shouldn't have to worry about those during PR reviews because people won't even be able to commit those things you set as errors. You can also use tools to format code in this stage so all code will have consistent indentation and styling, which I find really valuable because it's easier to review and read code if it's formatted consistently (at least to me personally).
Using git hooks will also make it so that you don't have to enforce certain tools or IDEs for developers, so they can use whatever editor they want, your hooks will still run and do their job.
Of course, before that can work, you need to find linting tools you want to use and agree upon certain "standards" you want to enforce. For example, if doing JS/TS work, you will probably use ESLint and you just have to create your own ruleset or use some of the existing ones if you agree with them. Prettier can be used to format code, again if talking about JS/TS or even HTML and CSS in Prettier's case.
I think you will never be able to enforce things to achieve super clean code and that's fine. We sometimes get obsessed too much over "clean code" when many times we just need "code that works". Of course having a structured codebase helps a lot, but there is no need to get super stressed about it.
Sometimes you just don't have time and things need to get shipped so you just whip a quick fix for something and place that "TODO: Refactor this" comment that then stays in that code for 5 years without ever refactoring because it just works and that's the most important thing at the end of the day.