I mean, unless the code is being used millions of times per second, does it really matter? When I was a beginner programmer, I constantly fretted that my code wasn't as efficient as it could be. Now I think I'm beginning to figure out that wasting my mental energy over these kinds of issues is a lot worse than wasting a half dozen or so computer clock cycles. For the kinds of jobs Perl is good for, and unless you are stuck with some a 286 microprocessor, it probably isn't worth the trouble of writing super-efficient code---especially when it makes the code more difficult for newbies to understand.

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop Pontiff";
$nysus = $PM . $MCF;
Click here if you love Perl Monks

While you are correct, I like to keep to what I think are best practices in my regular coding.

For me this means
attempting to maintain consistancy of style across a codebase
utilizing idioms as much as possible (unless using another mechanism provides better readability)
attempting to do as much I/O as possible at once to minimize waiting for a resource to become available again
scoping my variables as tightly as possible, and if they are needed elseware returning a reference to the data as opposed to the data

So from my angle of best practices, its a natural extension to only request the pieces of data I am actually going to do something with. If I only need the month from localtime I do

my $mth = ( split(/\s+/, localtime) )[1];
[download]

I dont need the other values, so why waste the RAM and cycles building the lvalue list only to use a single element? Granted here its slightly contrived, but in more complex code, only building what I need, and returning only what is essential tends to turn out a more maintainer friendly codebase in my personal experience.

Update: I don't know that I was clear in how I make the jump to only capture the data I'm going to use, based on the list above. I try to keep the codebase trim, as the more keystrokes the easier for a bug to creep in (yay strict, warnings, boo logic errors :P). So from there, its an extension to keep the number of variables down. I guess I should also add judicious use of comments to my best practices list. I comment blocks, and particularly interesting lines (ala, splitting some value and pulling elements, I will generally to something like # 0: foo 1: bar 2: baz).

MMMMM... Chocolaty Perl Goodness.....

While you are correct, I like to keep to what I think are best practices in my regular coding.

Of course, you shall keep on on your best practices. But there are more best practices than only one. One is to program very efficient, the other is to guarantee a simple maintainance and readability. Both ways are there for avoiding problems in the future, but there is no best best practice.

I would have also used the /^(...|...|...)$/ way. My most important reason would have been, that it is easier to read. The extra ?: doesn't have an influence to the algorithm done by the program, it only influences the internal way Perl is handling the regexp and its global variables. But the two extra character are confusing our eyes, making it a bit (really only a bit, but why should I renounce it) more difficulty to understand the algorithm some years later.

That doesn't mean, you're on the the false way, I only wanted to clarify that it is correct to give a beginner a simple, but (still) productive way, unless the speed penalty really hurts.

You gave another excellent example:

my $mth = ( split(/\s+/, localtime) )1;

I would have written it either as:

use POSIX qw/strftime/;
my $month = strftime "%m", localtime;

or

use Date::Simple;
my $today = Date::Simple->new;
my $month = $today->month;

allthough both ways are much slower than your suggested one. Both have the benefit that you don't need to know what the magic 1 is referencing in the time array to (what can be a great benefit if some other or myself in one year) has to maintain the code. (In addition you can avoid extra calculations to the month as they range in the natural 01-12 or 1-12 way and not from 0..11)

Greetings,
Janek