A subjective code review comment asks for change because of personal preference rather than a work ticket, coding convention, demonstrated defect, or clear edge case. Examples include complaints about indentation or styling and unsupported suggestions. Such comments make authors investigate the reviewer’s reasoning, delay reviews, and can create resentment when both solutions seem valid. section 6.1.1
Before letting preference shape a review, check whether the comment has an objective anchor:
- Trace the requested change to a work ticket or previously agreed functionality. section 6.1.1
- Identify a coding convention, obvious flaw, or edge case rather than presenting a personal stylistic preference. section 6.1.1
- Explain why a valid implementation is inadequate instead of making the author ask for the reasoning afterward. section 6.1.1
An unsolicited preference
A reviewer requests extra behavior for a new getSelected() method, describing several things they “would have loved.” Because those preferences were not part of the prior feature discussion and identify no flaw or edge case, they are subjective review comments rather than grounded change requests. section 6.1.1
Figure 6.1 From a pull request for the materialize repo
View a concrete pull-request example of a subjective comment and the ambiguity it creates for the author. section 6.1.1
