Yeah, totally agreed. My general principle on method names is: suggest an alternative, but it's a purely-optional suggestion. Sometimes I can think of a far more effective name for something, and I'll suggest it, but say "not required, just suggesting". There are a ton of things in code reviews that could be improvements, but are also not a big deal, or quite subjective. Then there are the things that seriously affect code quality and future maintainability, which would be the kind of thing that should hold up the review until improved or corrected. In either case, being completely clear and straightforward is always a solid approach. Asking weird rhetorical questions (as opposed to clear and direct questions) does not help the process and generally elicits uncertainty and self-doubt in the code submitter.