When I'm teaching Perl, one of the principles I always try to drive home is the importance of optimising your code for readability. You should always assume that the next person to look at your code a) won't be you and b) won't be as clever as you. Don't put unnecessarily complex code into your programs. Good advice (I think). I always try to code with those rules in mind.
Then, whilst showing someone some of the code I've written at work, I came across this:
foreach (@in) { my ($count, $file) = split; $file =~ s/^$in_prefix//; my ($campaign, $month, $fname) = split /\//, $file; $_ = { campaign => $campaign, month => $month, file => $fname, count => $count, sort => "$campaign:$month:$file" }; }
@in starts off with each element containing a string consisting of the number of lines in a file and the full pathname (yes, it's the output from wc -l). After the code has run, each element contains a reference to a hash containing data about the file.
But's really not very clear what it's doing or (worse) how it does it. The code should really be rewritten to something more like this:
my @files = map { my ($count, $file) = split; $file =~ s/^$in_prefix//; my ($campaign, $month, $fname) = split /\//, $file; { campaign => $campaign, month => $month, file => $fname, count => $count, sort => "$campaign:$month:$file" }; } @in;
Creating a new array has got to be better than mysteriously transforming one.
The worse thing is that this was code I wrote in the last six months. I don't even have the excuse that I was young and didn't know any better :)
--"The first rule of Perl club is you do not talk about
Perl club."
-- Chip Salzenberg
In reply to Do as I say. Not as I do by davorg
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |