Re^2: In Need of Mentoring

[qazwart]

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.

[Tux]

You mention several "changes" that you perceive in code over the time, and you seem to imply that most of them are "improvements".

I for one do not see the move from what you call old style to OO-style an improvement if it is done only for that reason. OO-style has its merits in a lot of cases but it being more moderd by perception is never a good reason to refactor code. Never.

The thing I miss in you very elaborate and well readable posts is what I think is the most important thing in module code: consistency. Reading your posts, I have a gut fealing that your documentation is in good shape. You seem to be capable of explaining your thoughts and goals which imho is an indication that you do so in the docs too.

As others have said, your target audience is important. If you are backporting new(ish) features from perl5.12 to perl5.older, you really care about what versions run the code on what architectures. CPANTESTERS is your help there as I presume you do not have 100+ perl releases running on 40+ architectures. If you are indeed making your code to run on 5.6, some more modern syntax won't even be available.

If your code is aimed at maintenance by many (a public git repo is a nice start), make your style guide public. Explain where your decisions stem from and "force" a style on the other coders. Using Perl::Tidy (perltidy) - and providing a working .perltydyrc can help the others. With what I started: consistency is way more important to be able to read code from others that to follow the style-du-jour.

[JavaFan]

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.

Oh, this is such a load of bullshit.

If you're picking up things like this from your "mentoring", please, immediately log out to Perlmonks to never return, and cancel all your mailing list subscriptions. You would become a better Perl coder if you don't listen to people and parrot their unfounded opinions.

Exporter doesn't invade any name space. Exporter exports exactly what the user asks for. It just that some people cannot grasp the notion of defaults -- Exporter has a way for the user to say "gimme your defaults", and for the exporting module to say "these are my defaults" (@EXPORT). People confuse that with "invading your namespace". But they're either mistaken, or just parrot others without thinking.

Second, making code OO just to avoid using Exporter seems like very bad advice to me.

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.

I've no idea about the latter, but considering a C style for loop to be bad programming is of course, utterly crap. It's like saying "using keys and each is bad style programming, you should use values". There are many cases where it's useful to know the index, or where you actually may not process all the elements in order and in isolation.

We're now suppose to eliminating extra parentheses because it's more readable.

That's a new one to me. Which church did you go to, and which preacher said this?

Yet, Rule #27 by Conway is to use underscores for separating multiple words in Perl variable names.

You know, Conway isn't a prophet, and his book isn't a gospel. Read the introduction, he even says so. By all means, if you prefer camel case, use camel case.

This is why I've asked about mentoring.

Actually, it looks like you want a preacher. You seems to desperately trying to avoid deriving your own conclusions, and you seem to want someone who can think for you. Which is the entire concept of religion: having someone else think for you.

It's ok to listen to arguments. Listen to arguments from multiple sides. But do draw you own conclusions. Which neither implies going with the loudest people, or with the majority.

Given your state of mind, I'd say getting a mentor is about the worst that can happen to you.

[tospo]

++ for that great story about the friend of a friend :)