I want my important perl statements or logic to stand out in my code. This is partially because I think it's easier to read that way, and partially 
because I hate it otherwise (see IHateIf). 

<p>
Say you have a run of the mill regexp with some matching going on. You sit there looking at the text you want to parse, and you build out your regexp. After 20 minutes of test matching for your 3 items of interest, it works for all the cases you can see, and it now looks like:
<pre>
    my $parser = qr!(SALE|REFUND)\t(Y|N)\t.*[\*x\d]{10,}\t(\d+\.?\d\d?)\t(\d+)!;
</pre>
That's wonderful. Only I think it's completely illegible to someone just glancing at the code. We can make the important parts stand out by using the 'x' regular expression modifier to add some meaningful whitespace to group the important parts of the regexp, like:
<pre>
    my $parser = qr!(SALE|REFUND) \t (Y|N) \t .*[\*x\d]{10,} \t (\d+\.?\d\d?) \t (\d+)!x;
</pre>
This is better, but not great, as we're not sure why things are being grouped that way. Granted, documenting this would help, but it doesn't make regular expression creation or management easier. If regular expressions are created from smaller regexps, the regexp naming helps document at the same time we've broken a complex problem down into smaller parts (while also highlighting the components in your editor).  
<pre>
    my $type   = qr!(SALE|REFUND)!;
    my $isGood = qr!(Y|N)!;
    my $money  = qr!(\d+\.?\d\d?)!;
    my $parser = qr!<a href="">$type</a> \t <a href="">$isGood</a> \t .*[\*x\d]{10,} \t <a href="">$money</a>!x;
</pre>
That's better. We even noticed that the (\d+) at the end is a fourth unnecessary match and got rid of it. But now our $parser regexp is at the bottom of all these other regexps, i.e. you have to read to the bottom of the stanza, putting all the helper variables in your mental stack until you use them with $parser. That's p00h for legibility. 
</p>

<p>
The bad thing is that we can't just yank-put $parser up to the top because we need to evaluate the helper variables first (we don't have lazy evaluation for perl5 variables). Luckily, TMTOWTDI to the rescue, we can do:
<pre>
    my $parser = qr!<a href="">$type</a> \t <a href="">$isGood</a> \t .*[\*x\d]{10,} \t <a href="">$money</a>!x if ( 
        my $type   = qr!(SALE|REFUND)!,
        my $isGood = qr!(Y|N)!,
        my $money  = qr!(\d+\.?\d\d?)!,
    );
</pre>
Amazing! Here we actually have an <b>if</b> helping us write good code (IHateIf). I like the layout because the variable assignments are de-emphasized (indented), while we finally establish the primacy of the $parser; it goes on the reader's stack, and we immediately start scanning trying to dereference the helper variables, which are right there for you to go "Wow. That's a smart way to do that." ;)
</p>

<p>
<i>May TMTOWTDI be with you always</i>
</p>