• It's code, you can think of it as art but in the end it needs structure.
• first review functional, after that review code-styles -> nothing annoys more than formatting the code 3 times and get an "obvious" logic error that has been there before.
• try to keep in mind: taste != right -> we all have different styles and approaches to solutions. if I review something and I don't like the style. I will mention it + why I would do it otherwise or even read up on it and ask why it was implemented that way, but that's it.
• Always stick to constructive criticism. put simple: don't just complain over it, add some feedback + a solution
• try to use a code-formatter or something that eliminates useless bracket or whatever discussions. We don't want waste time with superficial discussions or updating a "coding standard" wiki page that will be opened 1 time ;D ...
• appreciate nice solutions ! don't forget we all need positive feedback as well.

That at least how I review the code of my colleagues.

[has been edited]

To the other 2 good comments from j and Behrad Khodayar I would add the following:

• try to stay consistent with the existing code base.

I don't think it comes to personal preference, but more to be able to fit our own code into an existing project.

An example would be the use of existing modules (classes, functions) instead or re-writing some basic functions.

Or even putting the code at the right place. I have seen some "patches" in main controllers but this should have been separated into a new container and simply called from the controller (like all other functions that controller calls...)

Let's say consistency is key for maintenance later.

I wrote a long series about code reviews several years ago. Perhaps some of the advice I gathered will help. cio.com/article/2431557/developer/running-an-effe…