Well I tend to make comments in several general areas and each type might be handled differently.
Required changes. These are the kinds of changes where I point out that the code doesn't meet the functional requirements or doesn't work and must be fixed before being pushed to production. I tend to be very straightforward in these comments. The requirements says..., this does not do that. Or this will fail if the value sent in is null (especially when you know that case will occur based on the data that will get sent in).
Then there are the "this works but here is a better way to accomplish that" comments. You have to be more gentle in these and do more of a sales pitch. I might say that I would do this instead because it is likely to be better performing (I generally review SQL code where performance is very important). I might add some details about why it is a better choice just like I would do in answering a question on Stack Overflow. I might point out that it isn't required to change this for this particular code, but to consider the change in future coding. Basically with these types of comments I am educating people with less experience on what might work better.
Then there are the "this works but we do things this way" comments. These will probably also be required changes. These would include comments about company standards or the architecture we expect them to use. I would reference the standard or architecture document and tell them to fix to the standard. The comment would be straightforward but neutral, it is missing thus and so or the variable names don't conform to our naming standard or simliar things. For instance, our architecture for SSIS packages requires the package to use our metadata database to store particular information about the package and requires particular logging. The package would work without these things but they are required for company reasons (we need to report of the success rate of imports for instance or analyze the types of errors we receive.)
The one thing you don't want to do in code review comments is personally attack someone. It can also help if you find something they did well and point out that was good. Sometimes I learn something new from a code review and if I did I tell the person that.