In the developer space, it's astounding how fast new technologies are arriving. In order to stay current, a developer has to become digest the new tools and approaches, ty to get some hands-on with them and then possibly retain that new knowledge without being in a position to use it day-to-day. Contractors or consultants, especially, need to be able to keep their tool belts well stocked with the a wide assortment of tools, technologies and methodologies both because of not being able to predict which of them the next client may utilize and also because since the right tool always makes the job easier it makes sense to have as many as possible.
With all this in mind, when it comes time to hold a code review, upon what criteria will the code be judged? We all have our favorite approaches to designing software...our favorite code constructs, favorite tools, naming conventions. How does one prevent a code review from degenerating into a argument about which is correct? In my view, there is only one way.
Each team needs to spend the time, up front, to determine what standards the group will use. How are exceptions to be handled? Where is configuration information to be stored? What, if any, frameworks or external components are to be used? What unit tests and comments are to be created, minimally? By doing this, the code review becomes an opportunity to measure the code being reviewed against a known and agreed upon standard. This makes the review much more beneficial to the developer responsible for the code and offers a chance for the group to identify problems or omissions in their group standards and correct them.
Subscribe