As a developer regularly sought after to provide PR input, I know being an effective reviewer can appear as an art form. In reality, thoughtful application of a simple set of rules is all it takes to succeed.

Before jumping into the how, let's discuss the why.

Why should you care about being an effective Code Review-er?

The PR process is about more than catching bugs before production. It gives an opportunity to spread knowledge across the team, raise the standard, and guide the codebase's future direction.

For the participants, it is a prime chance to learn from each other, and impart your technical influence. Both sides are vital to your growth as a dev.

Now that you care, how can you do it well?

• Ask questions to clarify and to suggest. Avoid demands. Prefer asking, "Have you thought about naming this, ___". Don't hesitate to say "I didn't understand this section. Can you clarify?"
• Use neutral, non-personal language. I'm a fan of "Prefer <approach> if possible" & "Avoid <approach> to prevent <future problem>". Never use words like "dumb" or "stupid".
• Reference a style guide. If you don't have one, use a well known public guide that matches your language and framework. Let it provide credibility and avoid turning the feedback into opposing opinions. Even better, a good guide will contain the why alongside the what. Reference the why to validate your suggestion.

Above all else, remember there is a human on the other side of that code. We've all been guilty of getting attached to our code, be respectful and enjoy the collaboration.