Code reviews are generally underrated. From my perspective and experience , if they are being conducted properly and successfully , which means that you don't fall asleep in them, they are the most productive tool to spot out bugs, performance issues, scalability and extensibility traps and bad implementation of a good (or even a bad) design. But, and there is a big but, they can be intimidating and uneasy if the expectations are not set correctly. I always try to explain what are the expectations who will be examined in the code review so that the presenter would have the chance to prepare better for the review.So to make sure your team's code reviewer won't be thought of as the grim, err, code reaper , try to set some expectations first.
Below are my two cents for preparing and setting the expectations for a code review . They are relevant both for the presenter and the reviewer.
Have fun :
Before getting into specific code stuff , make sure that your product follows the following rule-of-thumb quality measurements:
- Satisfies the requirements
- Self Explanatory , the final product should be compared to the requirements document/spec.
Robust
- Stable, can handle and recover from systemrelated issues. Things like losing the connection to the DB, Mail server is down , etc.
- Debugging tools - Error, usage and debugging logs to help address system issues.
Handles wrong inputs
- Validates customer/system input errors : wrong types (string instead of a number) , special characters, SQL injection strings, etc.
Scalability
- Easy to increase the system's scale , examples :
- The system can support adding additional web/sql servers to balance the load.
- The system can support running in multiple threads/process instead of a single process/thread - relevant as there is an obvious trend to use more and more multiple cpu computers.
Extensibility
- Easy and simple to extend the system's capabilities and features.
- Promote Reuse, keep modularity programming mind set, write inline code comments and developers focused documents (UML diagrams and charts), keep the system compatible with the latest market technologies.
And to be a bit more code specific:
· Make sure you keep consistent naming conventions
· Make sure your code is well documented. The minimum is to make sure that each one of your classes has a roles and responsibilities paragraph, and functions and their parameters have a meaningful explanations.
· Keep your code clean and tidy - Make sure that variables which are not being used get removed, remove any development debugging related code, etc.
And here are some even further peer review tips
http://weblogs.asp.net/tgraham/archive/2003/12/19/44763.aspx
http://www.macadamian.com/index.php?option=com_content&task=view&id=27&Itemid=31
http://wiki.openlaszlo.org/Code_Review_Checklist
http://ncmi.bcm.tmc.edu/homes/lpeng/psp/code/checklist.html
Any other good code review tips that you can think of ?