I’m a massive fan of code reviews. They benefit the projects, the individual and the overall team for a number of reasons.

• They help increase the capability of less experienced developers by spreading the knowledge of more senior members of staff.
• They help the entire team to gain insight of how a particular area of an application has been implemented (ever had that one developer who knows how something works go on holiday without handover?)
• They help ensure coding standards are met, unit tests are written (and pass) and that the code is comprehensible (if a reviewer can’t work out what’s going on, he can’t review).

Over the past few years I’ve reviews thousands of pull requests, but I’ve noticed a difference in the way that developers approach submitting a Pull Request. Some prepare for it similar to how you may submit an essay, or a book for publishing, but some treat it as simply a road block in getting their new feature live and simply “chuck it over the wall”.

Review your own code before you push it for review. Tidy things up. Run through it as if you were approaching it with fresh eyes and make sure it makes sense. Remove any mess that IDEs occasionally create (added whitespace – because who wants to review that?) and make sure that the only thing left is what’s needed to ensure your reviewer(s) are able to understand your code and (hopefully) merge your code as quickly as possible. It will make sure that your feature gets in sooner rather than later and you’re not wasting their time.

There’s plenty of tools out there that make checking what you’re about to push for review easy.