Manufacturing folks know that "quality" means "conformance to standards". It is possible therefore to have a high-quality Yugo and a low-quality Mercedes (judging the cars only by how closely they conform to what they are supposed to be).
So the key thing is how the standards are written. If you know the problem ahead of time, you could write documentation or, better, test programs, to enable people to judge conformance. Given a piece of code without a corresponding specification, you are left to judging its "quality" more subjectively. We all have our own standards when it comes to formatting, readability, etc., and there are generally (though not universally) recognized best practices when it comes to modularity, error checking, etc. As in life, the squishy stuff often matters more than the stuff that's easy to quantify. A useful albeit unsexy project that would be interesting to take on would be to come up with a style and best-practices guide to Perl coding. Does anyone have any links to starting brief, readable starting points: guides to Perl formatting, OO structure, etc.? -- Hey, check out http://www.mhook.com ! It's your mail in your pocket. -----Original Message----- From: [EMAIL PROTECTED] [mailto:boston-pm-admin@;mail.pm.org] On Behalf Of Uri Guttman Sent: Thursday, October 10, 2002 7:45 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Boston.pm] question & puzzle >>>>> "G" == GregLondon <[EMAIL PROTECTED]> writes: G> perl Golf judging entails reading in a script G> and running it through some pre-determined G> algorithm to come up with a score. G> shortest count wins, reflecting the script G> with the shortest code length. G> perl Style judging entails reading in a script G> and running it through some pre-determined G> algorithm to come up with a score. G> lowest score wins, reflecting the script G> with the best coding Style. the problem is the algorithm. i can write the same exact code with different names for vars, subs, etc. and one will be very readable in english and the other in (say) french. which is better? G> there is no judging of the judges, G> the script is predetermined in both cases. and the rules for coding style are always subjective. golf scoring is objective as length is can't be judged differently by different people. that is the difference between objective and subjective judging. compare the 100M dash to gymnastics. same for perl golf and coding styles. G> You've got three factors to play with: G> size, speed, and quality G> you can pick any two. you can actually get all three in rare cases. :) G> it's ALL subjective, by the way. G> size, speed, and quality are ALL made up, G> subjective terms. its just that G> size and speed map much more easily G> into objectively measured metrics. no, size and speed can be directly compared to other programs. length and benchmarks are the same for each person running them so they are subjective. quality is subjective unless you can come up with metrics for it. in some products that can be done but not many and it is very hard to quantify quality in software. G> mapping "quality" into a objective measure would be difficult, but G> would then make it easier for programmers to evaluate where there G> script is in the speed/size/quality triangle. that is the whole issue. you can't come up with quality metrics nearly as easily as you can for the other two factors. so golf is nice since you can tell who wins without trouble. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com ----- Stem and Perl Development, Systems Architecture, Design and Coding ---- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org _______________________________________________ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm _______________________________________________ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
