Most of the default Perl::Critic policies come from TheDamian's Perl Best Practices. The rationale for the policies can be found in perlcritic's verbose output, the POD (in this case, Perl::Critic::Policy::BuiltinFunctions::RequireBlockMap), and of course the book (page 169).

$ perlcritic 11119158.pl 
Expression form of "map" at line 8, column 12.  See page 169 of PBP.  
+(Severity: 4)

$ perlcritic --verbose 11 11119158.pl 
Expression form of "map" at line 8, near 'my @list = map "$_ beads", @
+colors, @grey_scale;'.
  BuiltinFunctions::RequireBlockMap (Severity: 4)
    The expression forms of `grep' and `map' are awkward and hard to r
+ead.
    Use the block forms instead.

        @matches = grep   /pattern/,   @list;        #not ok
        @matches = grep { /pattern/ }  @list;        #ok

        @mapped = map   transform($_),   @list;      #not ok
        @mapped = map { transform($_) }  @list;      #ok
[download]

Although Perl::Critic policies usually have a very good reason, some of them can be seen as stylistic choices and one can disagree with PBP if one knows what one is doing. The severify of policies can be changed via the config file, e.g.:

$ cat ~/.perlcriticrc 

severity = 3

[BuiltinFunctions::RequireBlockMap]
severity = 2
[download]

Generally speaking, the block form is more flexible and more readable, however the expression form of grep is pretty readable if you're just doing a regexp match:

my @results = grep /searchterm/i, @inputs;
[download]

When things get more complicated than that, I'd generally prefer the block form.

The expression form can run slightly faster if optimization is a concern.

FWIW, I agree with everything you said. However, I think you made a little error:

my @list = map( "$_ beads", @colors ), @grey_scale;
[download]

I think @list will not contain anything from @grey_scale, and would warn with something like "Useless use of private array in void context", because the assignment precedes the comma operator.

I do prefer the expression form with parentheses, though, partly because of an (I believe) obsolete reason which was that the block form would generate a new lexical space whereas the expression form wouldn't, so the expression form was apparently slightly more performant (on very large lists).

I also like making hashes with something like...

my %h = map +($_ => 1), @a;
[download]

...I guess because it seems the most generally correct, given the possible parsing bugs with Perl and map, but at the same time I can see that it's possibly confusing, especially given the "array in void context" comment above. :)

I think @list will not contain anything from @grey_scale, and would warn with something like "Useless use of private array in void context" ...

Ah, good catch!

c:\@Work\Perl\monks\Lady_Aleena>perl -wMstrict -MData::Dump -le
"my @colors = qw(a b c);
 my @grey_scale = qw(x y);
 my @list = map( qq{$_ beads}, @colors ), @grey_scale;
 dd \@list;
"
Useless use of private array in void context at -e line 1.
["a beads", "b beads", "c beads"]
[download]

Another set of parentheses is needed to include the second (and any subsequent) array:

c:\@Work\Perl\monks\Lady_Aleena>perl -wMstrict -MData::Dump -le
"my @colors = qw(a b c);
 my @grey_scale = qw(x y);
 my @list = (map( qq{$_ beads}, @colors ), @grey_scale);
 dd \@list;
"
["a beads", "b beads", "c beads", "x", "y"]
[download]

---

Give a man a fish:  <%-{-{-{-<

It was my intent for @grey_scale to be part of @list, but not have "beads" mapped to it. I have a few modules that are lists starting with or have a map in the middle of the list, here is an example:

Read more... (817 Bytes)

My OS is Debian 10 (Buster); my perl versions are 5.28.1 local and 5.16.3 or 5.30.0 on web host depending on the shebang.

No matter how hysterical I get, my problems are not time sensitive. So, relax, have a cookie, and a very nice day!

Lady Aleena

In the code as shown, "map" just melds in the array reference construction. Perhaps that is what you prefer.

I personally would either make a temporary variable to hold the map result; or rearrange the code to highlight map function. On the second note ...

'troll' => [ 'troll',
             map( "$_ troll",
                  qw(desert freshwater giant ice saltwater snow spectr
+al),
                  'two-headed'
                ),
             'trobold',
             @$tralg,
             @$throglin
           ]
[download]

As tobyink mentions, the expression forms can be slightly faster because they avoid entering/leaving a block, but the block forms offer just that: a block where additional lexicals can be defined. In more complex uses, the block form can therefore be needed.

The block forms are also easier to read when using map to expand an array into key-value pairs to load a hash — fat comma will not parse correctly without extra parentheses and I get confused about whether those parentheses will define the entire argument list or just the leading expression.

my %index = map { $_->key => $_ } @objects;
[download]

is easier for me to read than:

my %index = map (($_->key => $_), @objects);
[download]

I know I can ignore Perl::Critic's results on this and other issues, however, I do want code that is more acceptable by the community.

Hi

How come Perl::Critic::Policy::BuiltinFunctions::RequireBlockMap isn't part of your .perlcriticrc ?

If you pick the policies you would like to check your code against, then you dont have to ignore the results ;)

RFC: Perl-Critic policy: ProhibitInlineSystemArgs,

Re: The Most Essential Perl Development Tools Today

I haven't written it.

My OS is Debian 10 (Buster); my perl versions are 5.28.1 local and 5.16.3 or 5.30.0 on web host depending on the shebang.

No matter how hysterical I get, my problems are not time sensitive. So, relax, have a cookie, and a very nice day!

Lady Aleena

BTW, this node might be also interesting for you. Best regards, Karl

See also