I am meditating about how to encourage forming good perl-coding habits.
VSarkiss advises: Don't make a habit of calling subs with the &. You're better off ... using () -- and gives good reason (IMHO) for it.
tilly agrees, says he prefers (), too, but says I wouldn't say that that choice is the One True Rule that everyone should follow. Which I agree - TIMTOWDI.
But still: clemburg in his response to Is Perl the End-All? he says perl (because of it's flexibility) is ill-suited to development in large teams (which I agree - I am also struggling with it right now). His node has rather high reputation (I ++ too), and I believe that part of it is for mentioning CPAN, but also part of it for above mentioned feeling about development in large teams. There was another discussion here about some boss preferring Java or VBasic before perl - because of less coding freedom means easier to enforce and maintain coherent coding style across whole development team.
I have to say that I came into perl with experience in many less forgiving languages, so all this freedom often amazes me - and I like it, why not. I also understand that perl started as language for writing simple scripts, and many users are coming with admin needs and background, and all this freedom is just fine in small programs.
Perl idea of freedom is to give you enough rope to hang yourself, if you are tempted to. But sometimes I got paranoid feeling that there is enough rope around my neck, and I cannot feel it ... yet, but rope is still there. Sometimes I am making decisions without fully understanding the price I just agreed to pay.
Example: I started using hashes a lot, but then I read runrig response (last one) in Array vs. Hash (newbie perlguts), and now I am rethinking my design decision, using arrays where appropriate (Thank you, runrig, for pointing this out). I had gut feeling I could later pay the price for hashes, but it was simpler to begin with them - and then adding one more is even easier...)
If perl allows a lot of freedom, but in one way there might be later steep price to pay, I believe it is decent to warn. If your colleague has no time or temptation read why, it's better to tell "if you do not want to read all use CGI or die;, just believe me and use CGI", than let him hang yourself, right?
I know there is no one simple correct answer, a lot depends on personal preferences, many of perl hackers do not work in teams at all (so they do not think about differences in style), TIMTOWDI after all... But still, I will prefer if next perl6 was optimized more for writing projects in teams, and less for writing poetry and obfuscation. I know this is not going to happen, so I hope at least perl7 will be? ;-)
Back to beginning, for me very good reason to use notation function() instead of &function is also that with () I can immediately see it is a function call (in many languages). When trained to see this from start on, beginner's eye will just get used to it - in all languages coming next. That is why I like changing -> into . in version 6.
Basically I have group of colleagues which are just typing code in perl, and I would like to have some guidelines, but I am not in position to enforce them. They claim they have freedom to do it, because perl allows it. So I hardly can do something about it. And I know that is easier to learn good habits, than learn and unlearn wrong, and re-learn good habits later. And I cannot do anything for my colleagues (and my project).
So I was thinking what we (PM) can do for other monks around here. Sometimes I do not have time to read explanation why something is dangerous, it's faster just to believe gurus. Even if something is preferable in only 90% cases, if you are beginner and not sure why, it's safer to do it as gurus do - you have 90% chance to do it right. You do not want too much rope...
I hope my thoughts were not too obfuscated - I should put this into obfuscation, maybe... :-). Other than that - perl is just fine...
pmas
To make errors is human. But to make million errors per second, you need a computer.