|Perl: the Markov chain saw|
Re: Code review on script siteby Jazz (Curate)
|on Nov 27, 2001 at 01:34 UTC||Need Help??|
I've thought long and hard about this over the weekend, and agree with nearly all of the suggestions noted. I was also thinking of the flip side of the issue. (People who know me know that I always look on all sides before undertaking as large a project as this; some may call it procrastination, but I digress).
To date, no other perl archive-type site is planning a code review process. This means that everyone who comes to the site may think that the code listed on the site is crap and go to another site (same crap, but no claims one way or the other).
Not only may the viewership decrease, but methinks that an archive where 80% or more of the scripts are dubbed as "unworthy for use" may reflect poorly on the language it was written in. Perhaps even extending to the books or notables that recommend the site? Not to actual programmers mind you, but to the webmasters or beginners who are just looking for a little script that does x? Or to potential or newer programmers who will find the learning curve for "more acceptable programming skills" too steep? Whose first lessons in Perl was that "Baby Talk is okay"? Note that the current target audience of the guide is webmasters and newer programmers, not seasoned Perl programmers.
Ahhh, the joys of breaking new ground :)
Perhaps the solution would be to formulate guidelines that would make the review process a bit gentler on all parties, including the reviewers (/me braces herself for the reaction on that one). More in-depth code reviews can be solicited by each script's author for a fee (to be determined by an available reviewer or by consensus) or on an online community venue such as this one.
If I were a webmaster looking for a script, my primary concerns would be 1) cost (not a reviewable item), 2) will it work? 3) is it safe? 4) can I easily make it look the way I want it to? and 5) if something goes wrong, will I be able to understand and maybe fix the error?. I wouldn't necessarily be worried about mnemonic naming, scoping, or style.
tilly's outline addresses a lot of the concerns that I didn't originally recognize the importance of, so, let me try this again :)
What I've done here is reorganize many of the points noted above to categories. Each section will be granted equal weight and the overall score will be the aggregate of all categories. The only exception to the scoring is Security, which in addition to the basic score will be prominently red flagged if it fails.
Obviously, green = pass; red = fail.
Again, please allow me to assert that site is little more than an archive of scripts written in Perl. We want to provide basic code reviews in an effort to protect users and less-than-paranoid server admins from dangerous code (or code that does not meet even a minimal set of standards) as well as act as a starting point for more intensive Perl study on behalf of the code authors. The review must be comparatively basic in order for it to be done on that many scripts, particularly with a staff of volunteers. There will definitely be a comments section where reviewers can elaborate, if they wish.
In most cases, we do not have a (valid) email address for authors whose programs are listed on the site, so most will not even be aware that the code has been reviewed unless they stumble onto it themselves. It is probably safe to assume that the code reviews are being done for the users rather than the authors. In one respect this is ideal, because if a program written in Perl just trashed a server/database/etc., who would want to learn or use it (or continue to)?
Many thanks for all of your help, comments and suggestions :)