Sam's Blog > Basic

Readable Regexps: Why you should use /x

Sam Graham — Wed, 02 Jun 2010 09:53:00 GMT

Regexps are one of Perl's strongest features, but they're also one of the causes of Perl's greatest criticism: that it looks like line noise.

If you've ever had to examine someone else's regexp, or worse debug one, you'll probably agree that there's some merit in that criticism.

It doesn't have to be that way however, there's some simple steps you can take to make your regexps more readable and more maintainable, and this week we look at one of them: the /x modifier.

Did you mean +, not *, in that regexp?

Sam Graham — Wed, 28 Apr 2010 13:36:00 GMT

Continuing from my previous article "Anchoring Regexps", another common regexp mistake I see is use of * where the author really meant +.

So today I cover + and *: what's the difference and why does it matter?

Anchoring Regexps

Sam Graham — Thu, 22 Apr 2010 15:14:00 GMT

A common mistake I find whenever I look at someone else's regexps, is a failure to anchor the regexp.

This is often, in my experience, the single biggest thing you can do to improve the performance of a regexp: it's one of those things you should learn to do in every regexp where applicable, which should be almost every regexp unless you're specifically looking for "something somewhere in the middle but I don't know where".

So, what is anchoring, and why does it have such a big impact?

The Science of Naming

Sam Graham — Wed, 31 Mar 2010 12:09:00 GMT

I've been working on Template::Benchmark some more this week and I've hit a brick wall, one entirely of my own stubborn making.

One of the major roadblocks to releasing v1.00 is that I'm unhappy with the name of one of the major conceptual elements of the module: I want to come up with a better name and, it being a major element, I don't want to change it after I've moved to a stable release.

Naming things well is something I'm extremely fussy about and one I've thought about often, so the factors that make a good name seemed like a worthy topic for this week's blog.

Wrapping Benchmark.pm to auto-correct custom controls

Sam Graham — Sat, 27 Mar 2010 20:28:00 GMT

Last week, in "Monkey-patching Benchmark.pm to auto-correct custom controls", we covered how to monkey-patch Benchmark.pm into giving us the results we wanted, and saw that one alternative method was to wrap the module instead.

This week, we investigate how to do this, and see what unpleasant surprises lie in wait when wrapping a procedural module.

Some simple "white-space trim" benchmarks

Sam Graham — Wed, 03 Mar 2010 15:38:00 GMT

Laufeyjarson asked on Monday, about stripping whitespace from both ends of a string. The comments contains lots of suggestions, but no hard figures, so I thought I'd reproduce them here along with the code used to generate the benchmarks - it provides a simple example of how to write a quick and reliable benchmark.