|There's more than one way to do things|
You know, if I'm considering downloading something from CPAN (or from anywhere else, whether it's free or paid), I seldomly give a flying fuck whether the coding style is outdated or not. The only thing that matters is "does it solve my problem"
I normally don't give a FF either. It works, I'm happy. If it doesn't, I find a different module. However, I'm not using a module. I'm creating a new one, so I want to do it right. Coding style changes over time, but older modules don't reflect it. For example, many modules use @EXPORT which is now considered a bad technique because it invades the user's namespace. You're not even suppose to use @EXPORT_OK. Instead, your code is suppose to be object oriented.
I've seen modules that manipulate $^W to turn on warnings. I'm sure that was a good technique at one time, but we now have use warnings;. The use of the C Style for loop gets debated a lot. It's now considered bad programming, and I believe it's going to be removed from Perl 6. Yet, I was taught that for (;;) is a much better way to mark an infinite loop over while (1).
And, even basic coding styles change. We're now suppose to eliminating extra parentheses because it's more readable. When I learned programming, it was the more parentheses the better. Better adding an extra set rather than relying on a mistaken idea of operator precedence because it makes your code more readable. When I first learned Perl, I was taught the correct way to create variables was to $camelCase them. They're easy to type and very readable. Don't use $underscore_variable_names because it's no more readable, longer, and harder to type. Yet, Rule #27 by Conway is to use underscores for separating multiple words in Perl variable names.
Nor, can I rely on perldoc. How should I declare something is a base class? Should I use the @ISA list, use parent, or use base? I believe we're suppose to say use base, but if you look at perlboot, it tells you to use @ISA and use var.
This is why I've asked about mentoring. Like 90% of the Perl programmers out there, I'm isolated from the community. Most of the other people around me are C#, C++, or Java developers. They have no idea about Perl.
A few years ago, the head of development decided that my Perl scripts should too be put through a code review process. I thought it was a great idea. After all, our software depends upon it. It should be reviewed. The problem was finding someone who could review it. At my first code review, everybody else admitted they didn't know enough Perl to actually review my code. However, one person in the group had a friend at the bank, and his friend knows a good Perl programmer who's helped him out before. He'll have his friend forward the code to this Perl programmer for comments.
A few days later, I get an email from this friend asking me to review on my own code.