[koof]

I tend to agree with all of the principles here, with some caveats.

What if you find yourself giving so much direct feedback that you're basically rewriting the code via comments, time and time again?

Feedback or instruction that's not super direct has its place - we have to foster independence somehow. If I'm in a lead position, I have to be able to ask you to go work on a bug or think about something on your own, even if I could probably figure out an answer in a short period of time myself.

Trust must always be in the room in order to ask someone to work, whether it's in code review or elsewhere. If that trust is not there, more direct feedback/instruction can help rebuild trust, but it is not the end-all-be-all.

To tie this directly to the example: there may be points where I don't give a suggested name or solution in my comment simply because I haven't thought of one, and the reviewee may need to be able to accept that without them thinking I'm being passive aggressive. (I would do my best to communicate that context in those instances.)

[kdazzle]

I’m with you. If I don’t think a chunk of code is readable, I’m not going to rewrite it all for them off the bat. I’ll just say that it’s not clear and could probably use some cleaning up. And they can either push back, or do something on their own, or ask if I have anything in mind, or seethe silently and ignore me. If it’s complicated or seems like they’re struggling then I’ll ask if they want to pair on a solution.

Otherwise it’s kind of like - “why didn’t you just do this yourself if you had something so specific in mind?”

[lmz]

This works better if you both are in roughly the same time zone. It's not so great when you have to play "guess what the reviewer wants" with one day of latency between iterations of the review.

[doutunlined]

Your code reviews are doomed regardless if the feedback cycle is 1 day.