Image may be NSFW.
Clik here to view.
Code reviews, whether doing agile software development or using another development methodology, are an integral part of every quality process. They allow both the reviewer and the developer to learn from each other, and help provide valuable insights to new employees.
Many developers have code review checklists that they follow to ensure that code they review is up to their standards. There are a few items, however, that can be left out of code reviews:
1. Any error or warning that will already be caught by compilers or static analysis tools. These should be caught and fixed as practice before the code review begins. Let the process work and make sure that the team is aware that you will not be spending time reporting these back.
2. An obligatory comment. If the code is well-written and you want to say so, please do. Do not try to find a problem just so you can say that you found one.
3. A personal preference. You’re the worlds biggest fan of camelCase, but the rest_of_the_team love underscores. If the team has as a whole, agreed to let preferences be preferences, do not force your standard on others. If however, the team has decided to enforce certain coding standards, please do check for these.
