I gave a presentation on toxic code [OpenOffice] [Text] at the last Harrisburg Perl Mongers. The gist of it is that with perl, one isn't writing for speedy execution, but rather for rapid and correct development. Trying to keep your code succinct helps because the reader can concentrate on the logic.

sub process_transaction { # do work with each transaction my $t = shift; if ($t =~ /foo/) { foo($t); } if ($t =~ /bar/) { bar($t); } }

The above is certainly readable perl, but when I look at the same code written in a different format:

sub process_transaction { # do work with each transaction local($_) = shift; /foo/ and return foo($_); /bar/ and return bar($_); }

I find it easier with the second format to realize that I'm not covering all the possible parameters. I should have error-handling code:

sub process_transaction { # do work with each transaction local($_) = shift; /foo/ and return foo($_); /bar/ and return bar($_); /.*/ and die "bad parameter: $_"; }

Because perl (or any Turing-complete language really) has TMTOWTDI, the easier that we can reveal the logic in our code, the easier it becomes to see the errors that crop up in rapid development. Part of the answer lies in documenting how your code works, part lies in sharing a style guide with the reader (why people harp on idiom so much), and part lies in coding succinctly.

IMHO, the following makes the logic most apparent. I suppose that's why it's a good thing that TMTOWTDI. :) sub process_transaction { # do work with each transaction $_ = shift; return foo($_) if /foo/; return bar($_) if /bar/; die "bad parameter: $_"; }