After a long long wait finally I received my FREE copy of “Best Keep Secrets of Peer Code Review” which i order a couple of months ago. i ordered because of two thing the first and obvious one is because is free and the second one is that i really like to find my teammates bugs and code weaknesses also mines.
since I work on a Company that assures its Software’s Quality by implementing CMMI in all of the development stages; peer review is a must-do practice in order to deliver software with quality. if your Software Methodology does not include this practice then you could do better. applying PRC will dramatically decrease the number of possible bugs in the code you write and also it can help you identify some of your bad coding practices.
if you use a Version Control tool like SVN or VSS (please stop using this one!) then there are some questions that you should ask yourself, like When should the review of the Code need to be perform, before or after commiting? i prefer to Review before commit, but what would happen if a team-member works on a different location and you cannot reach his desk to perform the review, shall he email the code to the reviewer? i don’t think so because that will require some code integration effort. both approaches are good as long as you perform the review. if you want to go deeper then you should review this paper about Code reviewing in Open Source Projects.
A good practice in PCR is to have a checklist template for code review in order to cover all the common aspects of code like error handling, naming conventions, Code Comments ,if the code complies with the documentation, etc.
Nobody likes to be told that your Code was not well written. but nobody writes flawless code. so you should take care on how to provide the PRC feedback to your team-mates.
PRC cannot and must not be the only practice to try deliver bug-free software. PRC should be complemented with TDDand QA testing.