As of June 20th, I am now married. It was also my birthday and Father's Day (we just found out she's pregnant!), so I am not only a very lucky man, but I'm going to be totally screwed on presents.

And to make things relevant, I recently asked how to post to blogger.com from Perl. I was also asked to share the solution. Here it is.

I was reading Steve Haryanto's blog post about filtering Data::Dump output and immediately installed Data::Dump. If you use the debugger as often as I do, I recommend you install that module along with DB::Pluggable. That's when the delightful magic starts.

I now have my copy of the new edition of Effective Perl Programming. I'm halfway through another book, a wedding on the 20th and some other major personal (good) news, so I won't be able to review it right away. However, a few quick notes:

Pros

• Covers 5.12.
• A full chapter on Unicode
• Good discussion of testing

Cons

• Recommends SQLite for a test database (I used to like this idea myself).
• Needs better coverage of Test::Class.

(Can you tell the one chapter I've already read?)

I don't think the testing points are that serious; there needs to be a far more in-depth treatment of testing and for this book, it can't possibly cover this area properly. I also noticed it had nice things to say about Moose, but didn't use it in examples. I think this was the right decision, but I wish it weren't.

And in Web sites it recommends, blogs.perl.org is listed, but use.perl.org is not. Rather interesting.

In any event, those were just a few things I noticed flipping through the book. I'll have a better description later. For now, suffice it to say that it looks very, very good. Just a few of the places I've taken the time to read are well-thought out and show lots of experience.

A long time ago, I wrote this regex to handle a Perl problem I had:

$html =~ s{
             (<a\s(?:[^>](?!href))*href\s*)
             (&(&[^;]+;)?(?:.(?!\3))+(?:\3)?)
             ([^>]+>)
          }
          {$1 . decode_entities($2) .  $4}gsexi;

It didn't work. That not only taught me how to use a proper parser, it led me to write HTML::TokeParser::Simple.

However, some people still insist upon using regular expressions for parsing HTML.

How do you know when you should use a module instead? When the risks outweigh the rewards. Otherwise, go ahead and use that regex. We're here to get jobs done and we should know when is the right time for dogma and when is the right time to extract that href. Don't be afraid to use Perl.

(And when it's a full-blown production system and it's critical that the information is correct, I'll be the first to yell at you for the regex).

Beyond obvious problems with not using strict and warnings, here are some of my personal pet peeves regarding common Perl bad practices.

• Stop using indirect object notation

We already know it leads to subtle bugs. Why keep doing this?

my $foo = new Foo('baz'); # bad!

• DontUseCamelCase except for package names.

You want people to be able to read your code.

$foo = $DontUseCamelCase;
$foo = $do_use_underscores;

From "perlstyle":

While short identifiers like $gotit are probably ok, use underscores to separate words in longer identifiers. It is generally easier to read $var_names_like_this than $VarNamesLikeThis, especially for non-native speakers of English. It's also a simple rule that works consistently with VAR_NAMES_LIKE_THIS.

I could be mistaken, but I believe CamelCase was largely a holdover from Smalltalk which only allowed a leading letter and then optional letters and digits. TheReadabilityOfPerlIsBadEnoughWithoutCamelCase.

• Don't use Perl's lesser-known built-in variables unless you document them.

Just because you instantly know what $[, $*, and $; do doesn't mean others do. You're just making life harder for others unecessarily.

if (@errors) {
    local $" = ', ';
    croak("Embezzlement failed: @errors");
}

I have a bad habit of doing that. I have to stop that because it's not fair to maintenance programmers.

• Limit your lines of code to a reasonable number of characters.

I've seen CPAN modules where the lines of code force horizontal scrollbars in my browser, not just wrapping issues in my editor. Sure, I can resize my editor and I don't have to worry about old-fashioned 80 colomn terminal limitations. I haven't seen that in over a decade.

The real problem here is complexity: if you have a line of code which is 300 characters long, something's wrong. Even if it's a simple variable assignment, that implies you have a huge constant in your code. Why? And why make lives miserable for other people who simply don't want to carefully read through all of that to make sure there's a mistake? Keep your lines of code short and easy to read. Don't do too much.

• Stop being an @$$.

OK, this isn't about code, but it's still a common problem. Just because you're upset with someone or feeling superior doesn't give you a right to call them a f***wit. Maybe you're impressed with yourself or just can't contain your anger, but there's really no place for it in adult conversation. Hopefully you'll outgrow it and leave that to the **** programmers.