1. Does it work
2. Performance
3. Best Practices
4. Code Standards
Every company does this a little differently. You work up a set of standards and practices and hold people accountable for adhering to them. Some teams get mired down in #4. I would suggest that you not spend time arguing where closing and ending brackets go and stay focused on whether the code can be easily understood by someone else. Things like abbreviations should be avoided for instance. The developer coming in behind you might not know what the abbreviation or acronym means. Code purpose should be f'ing obvious to anyone with a brain. If it isn't, then you've done something wrong. Focus your reviews on those sorts of things.
Also keep this in mind, writing code is the same as speaking. Every human has a slightly different style. Too much conformity is not good for creativity. Too little is not good for maintainability. Use a common sense approach to find a happy medium. If #1 thru #3 pass the test on a block of code, be wary of whether your personal preferences for #4 interfere with someone else's ability to create. If you all wrote code the exact same way, we could just hire a robot.
If you are debating whether this approach
if (x == y) return false;
is better than
if (x == y)
{
return false;
}
or someone else prefers
if (x == y) {
return false;
}
Then your code review is a complete waste of time and money.