When someone asks me to review their code, I take it as an opportunity to express my opinion about code, but I don’t expect to convince the other person. I used to approach code reviews differently though. I used to think that code reviews are about making sure nothing “bad” ever gets checked in. Of course, there is something to that idea, but it’s easy to take it too far. The problem is that different people have different ideas about what constitutes good vs. bad code. While such beliefs often have coherent justifications, they are often held with religious ferver. When such beliefs clash, a code review can quickly reach an en passe.
I’ve decided that such conflicts are usually unwarranted. It may be that one person’s way is actually better, and that time would bear it out. Unfortunately, we do not have the benefit of knowing what happens in the future. Therefore, the “but this will have lasting consequences” argument does help one side vs. the other. BTW, this fallacy comes up in many areas of life. The weight of a decision does not justify any solution more than any other. It merely argues that the decision not be made lightly, which is often something that all sides agree on anyway.
Such differences in opinion practically never work themselves out during code reviews. Beliefs about how to code something are the unique product of personal experience. Often, one isn’t even fully aware of the source of those beliefs (again, this applies to life in general). Even when one knows (or thinks one knows), it rarely helps move the code review along, because the other person also has a personal well of experience to draw from. And yet, the problem remains: What code is to be submitted? Since there is little chance of convincing the other person that another way is better, there is little value in having an extended argument about it.
My general strategy (whether I am giving vs. receiving a code review) is to marshall the most cogent argument that I can, and hope to convince the other person. After that, I just do whatever makes it easiest to submit code. This is a bit easier when I am giving the review, because when I receive a review, I feel a much greater sense of ownership. I do feel that deference should be given to authors, because dampening enthusiasm by crushing one’s sense of ownership hurts productivity, retention, etc. This is not to say that reviewers should allow authors to run amok. It just says that reviewers should insist only on egregious violations. Don’t sweat the small stuff!