in reply to Named captures or positional variables

Nowadays I'd only use $1 etc. if they are used within something like 5-10 lines of the regex. Even then I often find myself writing my ($foo,$bar) = $str =~ /^(\w+)\s+(.+)/; instead of using $1 and friends. I think the only time I've used $1 recently is in a construct like if (/^\w+\s+(.+)/) { my $foo = $1; .... In your example case, I would almost certainly use named capture groups, since it looks like the regexes are defined nowhere near the $1 variables; I'd say there's too much of a risk of someone accidentally adding a capture group somewhere and throwing off all of the indicies of the other groups. Named capture groups can also help someone trying to understand a regex later on. So in general, I find having things named, especially stored in lexical variables (i.e. watched by strict), is always preferable from a maintenance standpoint. I usually only back down from that when the scripts are really compact and/or it's a throwaway script. As for performance, you know what they say about optimization ;-)

Replies are listed 'Best First'.
Re^2: Named captures or positional variables
by MidLifeXis (Monsignor) on Dec 10, 2014 at 20:44 UTC

    Funny you should mention that (performance). I just did benchmarks on the two parsers against a test data set. Only difference is the module used to parse the lines of text from the log files, parsers are set up outside of the benchmark, single initial run to prime to I/O buffers, etc. The results were within 2-10% either way, depending on the data set - $1 and company in the lead, but negligible in the big picture. Since the log files are stored on disk, I/O is the limiting factor at the moment. The parsing uses less than 15% of a single processor.

    --MidLifeXis