I am not necessarily a good example of a good reviewer, I have been the 'victim' of many reviews, and I have given a lot too. I am often tactless, and pedantic. I blame that on the fact that I am South African born.... but I have since moved to Canada, and culture here is much more sensitive to peoples' feelings. I'm sorry.
I have had to train myself to approach people differently, to be more empathetic about things, and to approach criticism in a different way. I don't always get it right, but when I do, it makes a big difference.
So, how to be a nice reviewer:
- assess the 'competence' of the person writing the code. You should be able to tell a novice, from an intermediate, and experienced coder.
- identify those key areas where a person should focus in order to elevate themselves to the next step, or two. Give advice that can be realistically applied.
- praise the things done well - reinforce the good things.
- always remember that the person who wrote the code is emotionally attached to it, and they were courageous enough to post it here for criticism. Respect that.
- provide positive actions to take as well as (or instead of) negative habits to break.
So, to review your review....
Your initial assessment for the bug is valid, but did you notice that the OP includes the following check:
if(head == null || n == 0)
That's a good thing, they have pre-validated their data, which is good practice. They should extend that validation to include the negative-n edge-case. It is a small oversight, really.
How about saying it this way instead:
It is good that you included pre-validation checks to ensure the state of the system and arguments, but you have an edge-case you do not cover, which is that
n may also be negative.
About the comments (I see now that the post has been edited.... hmmm rollback needed... but, in a bit...). how about if you said:
I struggled to understand the algorithm you are using. Your code has what look like meaningful names, but sometimes you need to include comments that describe the algorithm you are implementing. Good comments describe why you are doing things, not what you are doing. You have no comments, so it is hard to understand why you do what you do.