in reply to Do as I say. Not as I do

Still, I think that the second snippet is not optimised for readability: functions like map and grep are sometimes obscure even for programmers with decent experience.

Moreover, the block that map evaluates returns a hash reference, which could easily taken as a code block.

Why not simply using the first block, pushing the hash reference into another array, not @in, like this: 

push @files, { campaign => $campaign,
         month => $month,
         file => $fname,
         count => $count,
         sort => "$campaign:$month:$file" };

[download]

Just my €0.02

-- TMTOWTDI

Replies are listed 'Best First'.
(ichimunki) re x 2: Do as I say. Not as I do
by ichimunki (Priest) on Dec 17, 2001 at 22:34 UTC
    I don't agree that grep and map should be avoided. In a Unix environment grep is a tried, tested, and well known tool. Grep in Perl is essentially the same thing. Map is a gloried foreach loop simplified to assign a list to an lvalue returned from the associated code block. In fact, the word "map" is straight out of beginning algebra where we talk about functions mapping inputs to outputs.

    Which brings me to the root of this thread-- and the fact that I agree and disagree with davorg. I agree that he might refactor (and comment briefly) this routine. And I agree that map is the way to go. But why not take the code block out from inside the loops and make this an actual sub? Then we can give the block of code a name that offers a clue as to its function (alleviating some of the need for comments along those lines), and we can access the code from outside our map statement if we want/need to. And we can still call it from a map at that point:
    my @files = map {func($_)} @in;
sub func{ ... }

#or if we really hate the idea of a whole sub for this
#function that keeps the block hanging around when it's 
#finished being useful
my $func = sub { ... }
my @files = map {$func->($_)} @in;

    [download]

    Which keeps our map from getting obfuscated due to the length of the block it surrounds-- and probably the first example I give makes it easier to introduce newer programmers to this powerful feature of Perl. It makes it very plain that what's going on here is that a list of inputs is being passed into func and mapped onto a list of outputs.

    Using a sub we can throw this function after our main block and keep its internals out of sight and out of mind when we are reading the rest of the enclosing block. That way we don't obscure that layer of code with details about how we transformed the lines of the wc output into data for our program. Much more readable, imho.
[reply]
[d/l]

In Section Meditations