

Perl Programming Best Practices - hmade
http://ontwik.com/perl/perl-programming-best-practices/

======
dragonquest
Its so pleasant to find such resources spreading throughout the community.
Perl is one language which could've died easily given its undeserved write-
only reputation, but its thriving and making some very cool new stuff while
steadily negating the argument of being line-noise (Dancer comes to mind as an
excellent project to both read and use).

While Modern Perl and Perl Best Practices seem to be now the defacto texts to
follow in this field, I highly suggest to also supplement your learning of
_good_ Perl by reading _Perl Medic_ by Peter Scott. While its main purpose is
how to maintain a legacy codebase, its an absolute gem when it comes to what
type of Perl code you should be churning out.

~~~
sciurus
For those who aren't familiar with the Modern Perl book, you can download it
at no cost from <http://www.onyxneon.com/books/modern_perl/index.html>

~~~
com
I'd really like to follow up on this recommendation: I used Perl first as a
kind of sed and awk on steroids in the dark days on a VAX running BSD 4.3,
wrote simple CGI in it in the early 90's then later recoded a fax gateway in
Perl 4 on Solaris 2.4. Like many people, Perl for me was a useful tool, but
regularly unreadable, and admitting of very few good practices. In the end, I
moved across to other domain-specific languages and only dived into Perl
infrequently for data analysis tasks during the last 10-15 years. Writing the
same old unmaintainable, unreusable, script-like code, and hating it.

Modern Perl is a revelation! While the first hundred pages are a crystal-clear
recap of the basic language (and I found at least a couple of things there
that I didn't really know about), the chapters on modern object-orientation
(using Moose), exception handling, testing, maintainability, and what features
in Perl 5 to avoid are all pithy, to the point and well-argued.

If you're a (self-exiled) Perl coder like I was, give this (e)book a read and
see if you might jump back in. I have - and would second frameworks like Perl
Dancer as fantastic examples of what the Perl community is up to these days.

------
yarian
Was anybody else annoyed that the video spent too much time showing the
audience/presenter instead of the screen?

Follow up/related question: She mentions that the slides would be uploaded
online. Where?

------
smosher
Is perl5i really a good practice? I got a "PHP API" vibe when watching a talk
about it and immediately wrote it off. Am I wrong?

~~~
chromatic
perl5i performs the valuable services of integrating several useful but
disparate extensions into a single working whole, which helps to identify
missing features and to encourage collaboration. It's also much easier to
install and to enable.

I see it as an experiment as to where Perl 5 could be. Even though I might not
use it outside of personal projects, it's still useful.

~~~
smosher
I think it's lost on me because a lot of these simple problems it allows you
to solve with simple code are also equally specific problems. (In a "how many
times have you written this routine?" sense, my answer is almost always "once"
or "never.") I haven't seen a really good example without a better solution so
I've got that "use Kitchen::SinkToo;" feeling.

That's not a bad idea for personal projects if it does save you time.
Otherwise I'm not so sure. Experimenting is good though.

------
BasDirks
I felt like being really lame and recommending a best practice like: "Use
Python", but the devil interfered, and I actually find myself looking at Perl
resources.

~~~
phaylon
If you're interested in what (part of) the community is up to, I'd suggest the
IronMan feed (<http://ironman.enlightenedperl.org/>).

~~~
pyre
The fourth link on that page reinforces the 'write-only' image of Perl:
[http://www.samuelkaufman.com/blog/2011/04/29/lazy-sprintf-
in...](http://www.samuelkaufman.com/blog/2011/04/29/lazy-sprintf-in-perl/)

~~~
pnathan
Uh, it's fairly understandable?

~~~
berntb
I think pyre built his opinion of a programming language on the _humorous_
first comment in the link... :-)

(I don't really like overloading, monkey patching etc in any language.)

~~~
pyre
My opinion of Perl isn't that it's a write-only language. I just said that it
reinforces the 'image' of Perl as a write-only language. Same for stuff like
this (actual code I've come across):

    
    
      sub f { shift->do_something(shift, shift) }
      sub x { shift->do_something(shift)->do_something_else(@_) }
    

Or

    
    
      sub foo { grep { $_[0]->bar($_) } $_[0]->baz() }
    

Note that $_[0] is indexing @_ and $_ is a completely different variable.

~~~
berntb
You can find weird stuff in any language, if you choose bad code that break
Best Practices.

The default for shift is misused in your examples. 3 shifts of the same array
in one statement -- in which order will they be done!? I would personally have
to test with a one liner.

Perl's expressiveness make both bad and good things easy. (Etc, it is the
usual argument.)

~~~
pyre
That first example is better written as:

    
    
      sub f {
        my ($self, $foo, $bar) = @_;
        return $self->do_something($foo, $bar);
      }
    

The shifts all occur in order (at least in those examples). Another confusing
example:

    
    
      open(FOO, '-|') or exec 'cat', '-n', $file or die "Could not open 'cat -n $file'";
      while(<FOO>) {
       do_something();
      }
    

There are similar example in the Perl docs ('perldoc -f open'). "open(FOO,
'-|')" forks and the parent opens a pipe to the child. The open() call returns
1 for the parent, and 0 for the child, so the child executes the 'exec' while
the parent drops down to the while loop. The child then dies after the exec
command.

~~~
berntb
Sigh, that example from Perldocs is (as I dimly remember), a translation of
old C idioms.

I don't know what you try to prove by bringing up some trivially bad code
examples.

(I am not certain about the order the shifts would be evaluated, if I wrote
code like that. An attitude from my old C days, since you can trust Perl's
eval order. But I got what the pos code did.)

~~~
pyre
Sorry, not really trying to prove anything.

Though, I _have_ come across code that used those idioms from the Perl docs.
The code that it was buried in looked like it was someone that didn't know
Perl very well and was probably just copying from the docs. E.g. _everything_
had a function prototype, which is something I've rarely come across even in
'cute' Perl code.

~~~
berntb
Perl Best Practices isn't a new book. Pervasive testing took over the (Perl)
world a decade ago. There are lots of people doing serious development with
Perl.

But that kind of code won't go away, since Perl is a system administration
language. It will be the first language lots of people use for fixing things
in their file systems, batch download of web pages, etc. Such code will never
be pretty. And there is nothing wrong with that.

And btw, I'd use one of the many CPAN modules for fork/exec, but if I was in a
hurry I'd copy the Perldoc example. It is a standard idiom in the Unix world.

------
chaostheory
The best Perl practice I came up with for our ancient Perl scripts was to
convert them to Python. Easier to read and maintain, at least in our case.

~~~
pyre
This seems to border on flame bait. You can't call a situation where you
abandon a programming language due to lack of knowledge/experience (or just
due to preference) a 'best practice' for that same language. Calling
converting all your ancient Perl scripts to Python a 'Perl best practice' is
inviting a flame war.

~~~
chaostheory
Yeah I was a bit of a jerk. Just too many bad memories and I let my emotions
get the best of me. Perl 5 just requires a level of patience and dedication
that's just beyond me.

It probably would have been a bit more lighthearted if I replaced Python with
Perl 6 in my previous post.

