I always seem to have small misses in my PRs, more than I think others have. I am trying to develop good habits so I write code and catch those small errors.<p>Typical I write it and try to pay attention to the style of the repo, than run the tests. But often, there are small gotchas at my work that I don’t notice.
I always read through my entire diff in the PR preview (on GitHub, say) before submitting, and I find I catch many things this way (typos, small todos, small factoring improvements).<p>I get feedback that my PRs are very polished, and I think this habit has helped.
Can these small misses get caught by tools? If so, litter your pre-commit with them. Maybe tests? Make a point to add those if they help catch these errors. You want to automate as much as possible so you get quick feedback before it becomes a PR.<p><a href="https://pre-commit.com/hooks.html" rel="nofollow">https://pre-commit.com/hooks.html</a>
As others have said, tools like linters and formatters would be the first step. Vale is a great one for catching spelling and grammar mistakes in comments and code. If you can't get buy in, then just have the linter/formatter config locally in your repo and not checked in, I've done this when freelancing before. You can also write yourself a checklist to go through before asking for a review, check for common mistakes you've made before that can't be checked by a linter.<p>Sometimes I'll also do a PR review of my own PR before asking for someone else to review it.
We use linters like flake8 and black on my team to make the diffs as clean as possible each time. This makes it easier to spot every change to the code, which makes it easier to spot errors.
Smaller PRs. You won't miss mistakes if your changes are focused enough. No team I've ever been on has gotten mad about me breaking big changes into logical chunks whenever possible. You won't miss things in a 4 file PR, but you will in a 25 file one.<p>My other personal rule is that if I feel the need to leave a comment explaining a decision, it's probably the wrong one.
For sure as others have mentioned review it yourself in the web interface of whichever PR tool you use. (Generally after having a break first)<p>This is something of a superpower for catching things before review and in my experience makes the actual third party review pointless 95% of the time.
Normally the coder is the wrong person to test the program since we already know how it's designed to work. Better to have someone with no prior knowledge of the program, with you observing. Often can indicate valuable tweaks to ensure users better understand how to use it.
Using a UI tool (Sublime Merge) instead of the command line helps me a lot. I review every line I commit this way now. I caught a lot of mistakes like this.<p>Linters and other tools also help. They should run as a pre-commit hook.