Perl Programming Best Practices(ontwik.com)
ontwik.com
Perl Programming Best Practices
http://ontwik.com/perl/perl-programming-best-practices/
5 comments
There is also widespread adoption of tools like http://search.cpan.org/~elliotjs/Perl-Critic-1.115/lib/Perl/... out there to make it easy to enforce coding standards on Perl projects.
See http://www.slideshare.net/thaljef/perl-critic-in-depth for the slides to a presentation that I saw this week on it, and http://www.slideshare.net/search/slideshow?searchfrom=header... for other presentations.
See http://www.slideshare.net/thaljef/perl-critic-in-depth for the slides to a presentation that I saw this week on it, and http://www.slideshare.net/search/slideshow?searchfrom=header... for other presentations.
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
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.
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.
Even though it's aging, _Higher Order Perl_ by Mark Jason Dominus has some very nice techniques and practices.
http://hop.perl.plover.com/
http://hop.perl.plover.com/
Effective Perl Programming by brian d foy is also great, although a handful of the tips go a little into the dark side of Perl tricks.
Regardless of their slightly dated information, I'd add to your list the standard 'Perl Cookbook' by Christiansen and Torkington. Likewise 'Programming Perl' by Wall, Christiansen and Orwant. While not perfectly up-to-date, the reader should be able to immediately use the code and if necessary refactor later. Come to think of it the editions I have are of a same vintage as 'Medic' so same advice applies...
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?
Follow up/related question: She mentions that the slides would be uploaded online. Where?
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?
It's nothing like PHP, but I still find it to be a bit too much. strict and warnings? Yes. "use feature ':5.12'"? Yes. A metaobject system incompatible with Moose? No thanks. Autoboxing all references? No thanks.
I wrote a pragma called "no nonsense" that is a little saner:
http://search.cpan.org/~jrockway/nonsense-0.01/lib/nonsense....
You say "no nonsense" at the top of the lexical scope, then you get strict and warnings, the true value required at the end of the module is automatically added, and any non-method subroutines you import are made un-callable as methods. That's it.
(I personally don't use this, because it's a little too cute. I don't mind saying "use Moose; use true; use namespace::autoclean;" at the top of my classes.)
I wrote a pragma called "no nonsense" that is a little saner:
http://search.cpan.org/~jrockway/nonsense-0.01/lib/nonsense....
You say "no nonsense" at the top of the lexical scope, then you get strict and warnings, the true value required at the end of the module is automatically added, and any non-method subroutines you import are made un-callable as methods. That's it.
(I personally don't use this, because it's a little too cute. I don't mind saying "use Moose; use true; use namespace::autoclean;" at the top of my classes.)
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.
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.
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.
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.
Yes but you have to form you own opinion. Try it and see.
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.
If you're interested in what (part of) the community is up to, I'd suggest the IronMan feed (http://ironman.enlightenedperl.org/).
The fourth link on that page reinforces the 'write-only' image of Perl: http://www.samuelkaufman.com/blog/2011/04/29/lazy-sprintf-in...
Uh, it's fairly understandable?
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.)
(I don't really like overloading, monkey patching etc in any language.)
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(@_) }
sub foo { grep { $_[0]->bar($_) } $_[0]->baz() }
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.)
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.)
That first example is better written as:
sub f {
my ($self, $foo, $bar) = @_;
return $self->do_something($foo, $bar);
}
open(FOO, '-|') or exec 'cat', '-n', $file or die "Could not open 'cat -n $file'";
while(<FOO>) {
do_something();
}
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.)
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.)
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.
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.
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.
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.
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.
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.
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.
It probably would have been a bit more lighthearted if I replaced Python with Perl 6 in my previous post.
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.