Trying to do good code reviews takes an order of magnitude more work than answering questions. Of course it provides an order of magnitude more benefit for the listener, but there are an order of magnitude fewer listeners.

My fear if there is an official section for this is that the ratio between request/assistance will be seriously skewed. (And I say this as one of the people who makes an effort to respond to requests of the form, "I would like feedback on my code.")

Good point. Code reviews are more work - however I don't necessarily think that there is an order of magnitude fewer listeners.

These are my thoughts...

This has to be voluntary - people are busy enough already without more work.

I've seen a lot of really useful techniques and tricks in the various code examples floating around - but this has been somewhat haphazard. The sheer volume of syntax in Perl means there's a steep learning curve. Don't get me wrong, this is fun, but it'd be nice to see some examples of what people think of as best practice in Perl coding. The discussions here have helped me learn a lot.

I know that best practice is a nebulous concept (best for hacking, reuse, maintability, winning obscurated contests...). Some short suggestions can help a lot when someone is starting out. On the other hand people learn better by doing, so maybe this is too much hand holding, and maybe I should let people spend some time evolving their own styles anyway.

With coding, I've learnt most of my coding style/techniques from other people - there's a lot of different examples of perlcode out there that are easily available. However these can differ markedly in style -- and unless you're at an equivalent level of experience it can be pretty hard to see why people did things the way they did. Given the complexity of the perl syntax, this can be pretty hard to do.

Partly why I'm raising these points is that I finish up shortly in a job and I need to hand my code over to relative Perl neophytes. This means I need to strike a balance between cleverness/efficiency and maintainability/readability. Having a section dedicated to code reviews/best practice etc would help me tell them 'see this is why this looks like this'.

However having said all that, it looks as if the craft section is the right place for this after all. I was concerned about the volume for requests swamping legitimate craft questions but with careful moderation that shouldn't be a problem.

Thanks for your comments all!

Perhaps I should explain my "order of magnitude fewer listeners" comment.

I don't mean an order of magnitude less due to lack of interest, but because the pacing is so much slower that most of the potential audience won't keep on clicking back to that section. If you discuss a point over several iterations, given the pacing here that tends to be a several day process. There isn't much of an audience left by then...