That template is from 2000 (we're three versions of Perl past that time), was probably mostly developed even earlier, and while tye's advice is generally to be preferred over mine, I would call camelCase bad—or at the most defensible least, uncommon—Perl style.

To be fair, Your Mother is from before 2000 (though I don't recall using Perl v2 that year) and was probably conceived even before that. That is clearly enough reason to discount something with no further justificaiton. Oh, wait, I forgot to make a dubious style argument. Unfortunately, most have not seen how he dresses, so I'll omit that. (:

was probably mostly developed even earlier

Perhaps you are unfamiliar with the meaning of the words "updated" and "update"?

Actually, much (I'm not sure "most") originated before 2000. And I've updated it quite recently (and several times before that) and so anything from before 2000 must be some of the best of that style since it has survived unchanged for so long.

So, did you actually have any real critique to offer (other than the one style point)? I'm sure people would love to learn what can be improved and how (and why).

As to CamelCase, I'll disagree that it is bad and also that it is uncommon in Perl. I seriously doubt you are using the modules file_handle, ext_utils::make_maker, dyna_loader, auto_loader, math::big_int, or time::hi_res to name just a tiny fraction. And the motivations for using CamelCase in module names at least partly matches my motivations for using it in subroutine names.

Compare the output of perl -we "print this" vs. perl -we "print This" and you'll see that the second avoids:

Unquoted string "this" may clash with future reserved word
[download]

Unfortunately, it seems that most Perl guides pretty much ignore the problems with the following code:

sub log {
    warn timestamp(), "@_";
}

sub dump {
    log( Dumper( \@_ ) );
}
[download]

I expect a significant fraction of serious Perl coders to notice the problem with line 1 (I'm not sure if it would be more or less than half of them). I expect only a small fraction to notice the problem with line 5. I expect many to go so far as to deny the problem with line 2.

Personally, I much prefer a style that simply prevents all of those problems. Which means I updated my standard template to not use "sub main". The two routes I considered were CamelCase and under_scored. under_scored would have meant either "sub _main" or "sub main_" and the former of those already is well-established style for "private" and so would be quite confusing while the latter I consider rather silly looking and much, much more unusual than "sub Main", which is what I standardized on. (And going with "sub Main" with the intent of keeping underscores would lead to the Under_Scored_Capitalized style which I find rather "the worst of both worlds".)

I don't personally grumble when I run into under_scored-style identifiers in Perl code (much less go publicly proclaiming such to be "bad"). But I do dislike the relative difficulty of typing _, that fact that documentation about such identifiers usually ends up with the _ being wider than whitespace and thus the spacing conveys rather the opposite of what _ is meant to convey, and that things like HTML links often make such style very hard_to read with_confidence. While I almost never run into identifiers that get to the point of being difficult to read whenWrittenInCamelCase (and can't think of any other down sides to camelCase). So I personally consider CamelCase to be slightly better than under_scored in several ways and worse than under_scored in no practical ways. But I end up using both under_scored and CamelCase quite a bit in Perl code.

But, of coure, the point of that template has extremely little to do with what style one uses for their variable names. I really don't want anybody to declare a lexical with the name $putMainVarsHere.

As for some more "modern" alternatives, I actually prefer -w over warnings.pm for this specific case (and prefer neither for writing modules), though I do value and use warnings.pm in much more limited scenarios (but I won't go into the "why"s in this node -- though I have discussed at least much of that elsewhere around here).

I often prefer use vars over our, especially in modules. But I do use our when it is worth it. I'm probably even more likely to replace use vars qw( $Globals ); in that template with my $Global= ...;. But the distinction between any of those three choices isn't the point of that terse example, either.

Then there are state variables. A great many of the Perl installs that I use right now don't support such. It certainly isn't time for me to consider standardizing on using them. Nor do I believe that I'd always replace my current pattern even when state $x is an option. Actually, the next module I'll be putting on CPAN (perhaps this week) deals with this type of stuff.

- tye        

I've used that template about 10 times in the past month and it helped me avoid the pitfalls tye lists as justifications at least 5 times. To use your words Your Mother, And we were just discussing Dunning–Kruger the other day...

$history->Repeat();