Always remember - it’s a human being on the other end of the review
Review other people’s code like you’d like your code to be reviewed. To make sure you are communicating correctly, read your code review to yourself out loud and ask yourself, is this something I would want to be said to me? If not, think about changing the tone or content.
Give clear suggestions or recommendations
Never tell someone that the code needs to be fixed without giving suggestions or recommendations on what to fix or how to fix it.
It is never a good idea to write “Fix this” without giving more explanation. Why does it need to be fixed? What suggestions do you have to fix it? How might someone figure it out?
Always assume good intent.
Code may not be written how you would write it. Let’s say that more clearly: code is rarely written the same way by two different people. After all, code is a craft, not a task on an assembly line.
Tap into a sense of curiosity and appreciation while reviewing – curiosity to understand what the reviewer had in mind and gratitude for what the Coder did or tried to do.
Clarify the action and the level of importance.
If you are making an optional suggestion, for example, a “nit” that isn't necessary before the code is approved for production, say so clearly.
If you wonder why the person made a particular choice, but it doesn’t affect whether the code should make it to production, say so clearly.
If you are confident that the code needs to be fixed before it is ready for production, say so clearly.
Code feedback – and all feedback – includes praise.
Code reviews present an excellent opportunity to thank you and appreciate your colleagues' work.
If someone has written particularly elegant or maintainable code or has made a great decision about using a library, let them know!
It is always the right time to give positive, specific feedback-- in life and in code reviews.