-
Identification of any functional issues. However, most of the review comments are unrelated to any types of functional defects.
-
Pointing out missing validation checks or alternate scenarios (including corner cases) where the current implementation may fail.
-
Suggestions regarding APIs to use, designs to follow, coding patterns, team coding conventions or best practices.
-
“nit-picking issues” (e.g., indentation, comments, style, identifier naming, and typos). Resolution of nit-picking issues helps long-term project maintenance.
-
Feedback / questions to help authors to think about an alternate implementation or a way to refactor the code to make it more comprehensible (even if the current implementation may be correct).
-
Asking questions merely to understand the implementation. Those comments may be useful to the reviewers, but are not considered useful by the author as they do not improve the code.
-
Praising code segments. Those comments may help building positive impressions between the team members, and encourage good coding, but interviewees rated those as ‘Not useful’.
-
Pointing out future work, not planned for the current development cycle, or comments about code that was not related to the change at all, but simply existed in the changed files.