But then arturo suggested making it nice instead of mean. I do like looking at code and reading why it is bad and how it can be improved, I'm not sure I'm completely convinced it warrants its own section...we've got quite a few sections and there could be some confusion. And there's also the question of if anyone wants to correct code that the poster already knows is horrible (I assume anyone whose own code is having problems will post to SoPW). So I'd like to see posts like that, but I don't know that they need a section.

I could almost write a book; I wouldn't say the code I maintain is downright *horrible*, because it does get the job done, and it does a remarkably complex task. Also, the code author learned Perl as she developed this working code. Quite an impressive feat, IMO.

One part of this large system (of legacy code) I maintain is replete with globals, some of which get set in various subroutines, not a package in sight, very little thought given to code re-use, and 30-line subs that do things that a routine like


sub percent {
    my ($num, $denom) = @_;
    $denom > 0 ? sprintf("%2.1f%%", ($num/$denom) *100) : "00.0%";
}
[download]

does.

Philosophy can be made out of anything. Or less -- Jerry A. Fodor

They give an idea of what I'm talking about (and I want to emphasize that I think the best place for it might not be its own section, but a subsection of Tutorials )

One valid worry is that there's enough opinions out there already about "how to do it", and this might end up just duplicating what goes on in the best of Seekers of Perl Wisdom threads; the original post is clear about the goals, and provides some code that does not work as the author wants it to, and various monks chime in with their proposed solutions. I envision rolling up the process a bit, in that the first step would be posted by someone who took "bad" code and generated something he or she is proud of out of it.
MJD's second "program repair shop"

MJD's first "program repair shop"

Philosophy can be made out of anything. Or less -- Jerry A. Fodor

You guys inspired me, so I wrote another Program Repair Shop and Red Flags article which went up on www.perl.com today. The article takes an old crufty piece of Perl 4 code and tries to improve it. Here's the description from the web site:

Once again I take a real program written by a genuine novice and show how to clean it up and make it better. This time we turn a perl4 library into a Perl 5 object-oriented module. I show how to recognize some "red flags" that are early warning signs that you might be doing some of the same things wrong in your own programs.

Enjoy.

Those articles were very popular, and I'd really like to do some more of them. The problem is that it's difficult to find appropriate code samples to discuss. I don't want to use anyone's code without permission.

Does anyone have any suggestions about where I could find some novices who would be willing to contribute brief (20-50 lines) samples of code for review on www.perl.com?

I have always been bemused by the fact that even though both articles were good, neither used strict.

However the first one in particular is worth reading. Not so much for the information in it as the metrics that he is using. It is not so much, "This is better" as, "This is what I look for in deciding what is better." That is an important step to take.

Personally, I'm all for whatever form the idea takes.

At any rate, as I said, great idea!

Roy Alan

At least in the mean time, I think you should feel free to post bad examples and how to fix them to Meditations.

$object = Info_File->('camel.info');

$object = Info_File->new('camel.info');