As a result, I've lost hundreds of hours in code reviews because some pedant was more interested in picking nits over whitespace than actually reviewing my algorithms.
The places where I worked used a simple guide line: the author has to clean up trivial issues before submitting an item for review. In case of code, this means ensuring style conventions.
Which in practice is trivial for reasonably popular programming languages:
If some guide lines do not make sense for your shop, simply change them to fit your needs. For example, PEP8 recommends a maximum line width of 79 characters. However, all our developers work a horizontal resolution of 1920, so we allow 132 characters. We also changed naming conventions from the loud and baroque SOME_CONSTANT to the calm SomeConstant.
Next, there are tools to check these conventions such as CheckStyle and flake8. Often you can even find tools to reformat source code consistently or automatically fix trivial issues like missing blanks, for example autopep8.
Some shops inject these tools in the commit hook of their version management and make it reject any code that does not conform. Baring that, the review moderator is required to run the style checks on the review item. If it turns out that the author still left style issues in the code, the moderator returns the item to the author and requests to clean it up.
That way, the reviewers always get tidy code and can focus on comprehensibility, maintainability and algorithms.