Sometimes I'll open up the PR initially only to myself, and review it as if it weren't mine (or at least attempt to). I try to be open minded with it, and usually do fine some things that I'd missed when writing the code.
It can also help having your companies flavour of coding standards set up as linting rules. If you really want to go further than that, tools like SonarQube can be used to highlight more in-depth issues, like code repetition.
All of this can be done before being seen by one of your peers, which will mean a better quality of feedback that gets given on PRs.
From a reviewers perspective, one thing I would say is that it's important to leave positive feedback on pull requests, not just negative change requests. We can also change the way we frame our suggestions to change the tone of voice to something more positive and give more explanation. So instead of saying something like "don't use x, use y like we do everywhere else", we could say "have you looked at abc method? it uses y because we found it more readable than x".
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.
Sometimes I'll open up the PR initially only to myself, and review it as if it weren't mine (or at least attempt to). I try to be open minded with it, and usually do fine some things that I'd missed when writing the code.
It can also help having your companies flavour of coding standards set up as linting rules. If you really want to go further than that, tools like SonarQube can be used to highlight more in-depth issues, like code repetition.
All of this can be done before being seen by one of your peers, which will mean a better quality of feedback that gets given on PRs.
From a reviewers perspective, one thing I would say is that it's important to leave positive feedback on pull requests, not just negative change requests. We can also change the way we frame our suggestions to change the tone of voice to something more positive and give more explanation. So instead of saying something like "don't use x, use y like we do everywhere else", we could say "have you looked at abc method? it uses y because we found it more readable than x".