There has been some recent discussions at use.perl.org (in the journals) about code review, the conclusion being that it can be very rewarding if applied well.
The first thing to decide is the goals of the review : is it to ensure guidelines and standards are followed (in which case some elements can be automated) ? Is it to ensure that the code is of a certain quality, and if so how would that quality be defined? finally how and when would it be done ? I have seen very little code reviewing done in anger - once I reviewed some of the near-legendary Acme's code discovered that I needed to get a better understanding of Map, the other time I just ran some code past one of the more senior developers and he pointed out any problems he saw. This shows that often your more senior developers won't get their code reviewed well if at all, and that junior developers can gain as much from decent training as from review. I think one of the great things at a previous employer was that Seminars were held weekly on the technonology (HTML::Templates one week, CMS design another), and code was run past senior developers occasionally. When you combine this with documentation standards (we were working on that) and coding standards/guidelines (like always use strict and -wT, always pass by reference, avoid hash/array slices, always use /x and comments in regex's over a certain length, always use stantard configuration modules where possible, etc) you can have a very high quality of code and ensure that the work is a) rewarding for developers and b) of a decent quality so less time is spent wasting time/money firefighting. regards, A. _______________________________________________ Perl-Win32-Users mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
