A discussion in the chatterbox with kudra who suggested a "hall of shame" gave me the following, slightly more 'remedial' idea. (As she pointed out, we wouldn't want bad code popping up in searches; might confuse some people. But if it were clearly labeled...)

Why not have a "code clinic" section, where monks take some sub-par code and clean it up, offering explanations of why they make the changes they make? It would
sit somewhere in between the Code Catacombs and the Tutorials, in that it would take the material in the Tutorials section and apply it to a real-world problem.

I should point out that my comment followed arturo's
description of some horrible code. There've been
a few nodes discussing how horrible things can be
(I'm too lazy to look up more than one link),
but it's probably nicer to try to explain why things
are horrible and clean them up (as in Ovid's CGI tutorial
spec, and arturo's suggestion). I was actually just
commenting on how much fun it is to be cruel sometimes.

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

I should have put these in the original post. Both are posts on perl.com, both are authored by Mark-Jason Dominus.

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"

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.

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.

keeping in line with a clinical theme, and because I haven't been using the " key enough today.
People submit code to a "waiting room" queue.
A "doctor" admits the "patient" for review.
After a week(?), the doctor publishes a write-up.
when somebody elects to review code, that code gets taken out of queue/ e-mailed to him/ jammed into a 'code I'm reviewing' nodelet.
While it's being reviewed, nobody else can see the code;this reinforces the clinic concept - rather than having 50 people giving suggestions, one person can write a coherent analysis.
After the analyst publishes his work, the node becomes open for commentary by the public.
I imagine that there be some threshhold at which people may elect to review, Monk or better?