Perl Best Practices 288
honestpuck (Tony Williams) writes "I have to admit that I can bristle at books that try to preach, so Perl Best Practices was on a hiding to nothing when I came to review it. I also have to admit to being torn about the author -- after all, he is one of those poor fools who insist on living in cold, unenlightened Melbourne, while I live in vastly superior Sydney. On the other hand, how can I dislike a man who manages to place a quote that involves my favourite character, Lady Bracknell. from my favourite comic play, 'The Importance of Being Earnest,' in the first few pages of his book?" Read on for Williams' review.
| Perl Best Practices | |
| author | Damian Conway |
| pages | 492 |
| publisher | O'Reilly Media |
| rating | 8 |
| reviewer | Tony Williams |
| ISBN | 0596001738 |
| summary | Methods of coding to improve your Perl software |
Many years ago I read a marvelous article that explained why so may early editors and word processors supported the keyboard commands of WordStar. When it's first born, a baby duck can be easily convinced that almost anything is its mother. The small bird imprints, and it takes a lot to shift its focus. "Baby Duck Syndrome" affects programmers in a number of ways, not just their choice of editor, and Conway is walking right into the middle and arguing with your imprinting on almost every page. A brave man; fortunately he has the street cred to make you at least listen.
So I carefully placed my bias and bigotry in the bottom drawer and prepared myself. I discovered a well-written, informed and engaging book that covers a number of methods (hey, 256 rules, come on Derrick, 2 ^ 8 rules can't be a coincidence!) for improving your Perl software when working in a team. That means all of us when you remember an adage a guru once told me: "Every piece of computer software, no matter how small, involves at least a team of two -- me, and me six months from now when I have to fix it." Conway puts it differently "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
The first chapter outlines the why and where of the book. The why is to improve your code with three goals; robustness, efficiency and maintainability. The chapter finishes with a short exhortation to us to "rehabit." Don't like the word much but I applaud the aim.
Conway is far from timid. He jumps right in to the deep end of the wars, with formatting the appearance of your code. I thought the chapter was brilliantly written until he told me I shouldn't "cuddle else statements," at which point I realized what an ill-informed idiot he was. Oh, hang on. Hey, that almost makes sense. OK, that's a cogent argument for your point of view, Conway. I also have to admit that earlier you did say that your rules for this bit weren't gospel, that if you wanted a variation that was OK, just have a standard and make sure you can support it with a code prettier. Perhaps not a total idiot after all.
After successfully negotiating those shark infested waters, Conway -- obviously a man who knows no fear -- wades into naming conventions. Once again he gives coherent arguments, pointed examples and counterexamples. It all makes sense.
The book's page at O'Reilly has an example chapter and a good description, but no table of contents so here's a quick list of the headings:
- Best Practices
- Code Layout
- Naming Conventions
- Values and Expressions
- Variables
- Control Structures
- Documentation
- Built-in Functions
- Subroutines
- I/O
- References
- Regular Expressions
- Error Handling
- Command-Line Processing
- Objects
- Class Hierarchies
- Modules
- Testing and Debugging
- Miscellanea
The book is also well-written and well-edited. The order of topics covered is a sensible one, and the book is appropriately structured. It reads and feels as if you are being given the wisdom from many a hard-won battle coding and maintaining Perl code.
My one complaint is that I found it dry: you are reading through pages of argument and examples without much relief. Perhaps this book might be best digested in a number of chunks, making the effort to use the ideas from each chunk for a while before moving on to the next.
Every so often I read a book from O'Reilly that makes me fear that they are slipping, then along comes a book like Perl Best Practices, and I'm reminded that when it comes to Perl, O'Reilly authors wrote the book. Once you've rushed through Larry's book and learnt the finer points with Schwartz and Phoenix's 'Learning' titles, you may well find that this is the perfect volume to complete your Perl education. If you believe your Perl education is complete, then buy this volume and I'm sure you'll find a lesson or two for yourself.
This book is not really aimed at the occasional Perl programmer (though many of us would probably benefit from its wisdom), but at the person who is professionally programming in Perl and wants to produce better quality, more easily maintained code. For this person Perl Best Practices is a 9/10. For the rest of us, the 'rehabiting' process might be a little too arduous; personally, I'm going to pick a few of the chapters and work on those for a while, maybe naming conventions and variables. For me I'll give it an 8.
You can purchase Perl Best Practices from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
#1 Perl Best Practice (Score:5, Insightful)
Ofcourse if you're using Perl4 and below, you're out of luck...
Re:A "best-practice" in Perl is like... (Score:5, Insightful)
coding style (Score:2, Insightful)
Dumb review (Score:3, Insightful)
Re:Best Best Practice: Don't Bloat Perl (Score:5, Insightful)
That a joke? I don't think there's any language that can be fully understood after a 2-semester course.
Re:Perl Best Practice: Don't use it (Score:4, Insightful)
Best Practice (Score:1, Insightful)
We are here reading this review because we want to use perl, so f*ck off, RoR, PHP, Python fanboys. Everything you can do in those languages i can do in perl, with style, so i NO don't want to hear about the hype of the year.
I couldn't live without perl one liners and i found the review helpful. Like many said before, perl doesn't force you to write readable code, but it doesn't mean noone can.
Best practice would be "use strict;use warnings;" and using indents properly.
Re:Perl Best Practice: Don't use it (Score:1, Insightful)
what I wanna say: the standard perl script is quite short ( 200lines). then libs and their apis are more important than anything else.
Best Practices (Score:5, Insightful)
1) There are reasons to use Perl. Nothing REQUIRING it, granted, but that's true of any language. Python and Ruby inhabit similar but not identical niches.
2) Line noise reputation aside, Perl can be _very_ readable. Concise done correctly means that it says what it does and does it, without unnecessary compiler syntax effort. Concise done wrong means it's not obvious what you are doing. Perl gives you enough rope to hang yourself...kind of like computers, and open source in general.
3) As far as the book goes, I was eager to get my hands on it and learn, but worried that I'd find it too limiting and restrictive. The tips ranged from the obvious (strict and warnings), the non-syntactical useful (use code and documentation template for new projects), to the small but fascinating (make your hash names end it words like "for" or "of", so that normal usage is self documenting: $name_of{$user} ). Very few of the tips did I disagree with, and even though the book talks about the importance of HAVING standard practices over what those practices are, I'm moving my dept to adopting the standards in the book because my preference is often habit over any calculated reason.
Perhaps 50% of the tips have nothing or little to do with Perl and everything to do with programming, programmers, or users.
This is not a life altering book. It is, however, a high quality book with some very good tips.
They were given away to OSCON attendees... (Score:4, Insightful)
I get a copy for every new dev now. I'm not going to force them to use all of it, but it definitely makes them think when they start working on larger projects.
I'd also recommend MJD's Higher Order Perl if you want to go even deeper.
I always think it's funny when people argue heavily about hating to work to a "best practices" style. And then start agruments about how crap Perl is because it's unreadable. Anyway - I digress.
cLive
Re:Best Practice (Score:3, Insightful)
It's also not worth our time rewriting it.
Not too long ago, I discovered the results of operations testing on various languages. Python was the worst in every category except one, where Java (1.4.x) became the worst (Java 1.4.x was the second worst in most of the other cases). This benchmarking, however, was a couple of years old, so it's possible other improvements have been made along the way.
For doing various system administration tasks, file massaging/processing, and stuff like that, I find perl to be quick and easy to use. Mainly because perl's regex engine has been so highly optimized, it tends to run a lot faster. I also have general issues with languages that are white-space dependant for their syntax... which is why unless it's something really simple, I tend to avoid UNIX shell scripts too.
I've also had a Java addict compliment me on my perl style, syntax, etc, because it was clear and readable... and this was for a major financial securities project.
If you really want a "best practice," try writing clear, understandable code, regardless of the language you use. It'll get you further.
Sad comments on a great book (Score:4, Insightful)
More to the point, you will write crap in any language if you don't understand the conventions, idioms, and best practices of the language.
Perl is a lot like Lisp. You need to think in terms of lists before you see anything but the sigils and you tend to write "C in Perl". Further, until you see *good* Perl code, it's hard to know any better. Before this book, the book I'd refer people to was "Effective Perl Programming" by Hall & Schwartz. The goal was to get beyond "baby talk" and use the language well.
I'm about 130 pages into "Best Practices" and I like the book a lot. It's definately on the required reading list for any Perl programmers that we hire.
I can't say I agree with Damian about *all* the conventions (I really *like* "unless") but I agree with most of them, and having met him once, I'll admit that he knows more about Perl than I'm ever going to know, and more about computing languages and PROGRAMMING best practices than most of the people that have responded to this topic.
If you code in Perl often enough that you wish your code was better, you should pick up this book.
Re:Best Best Practice: Don't Bloat Perl (Score:4, Insightful)
Perl's syntax is very complex; it has a lot of operators and provides many different ways to do the same thing. This makes reading other people's code very difficult.
Everyone starts by learning a subset of the language, then building upon that by learning more after they've mastered the basics. You can write a lot of perl code without knowing half the syntax. The problem is, since everyone learns a different subset, reading someone else's code is impossible for a beginner, and unfamiliar syntax isn't something you can easily look up in a reference. A language like PHP has a simpler syntax and far fewer operators, and makes up for it by having a large number of functions; once you've got the syntax down, you can just look up unfamiliar functions in the documentation and figure out what's going on. The result of this is that PHP looks easier to beginners while Perl looks daunting.
I'm completely ignoring Perl 6, and I'd advise others to do the same for at least a few more years.
Re:Best Practices (Score:3, Insightful)
I tell you what turned me away from Perl, though: the syntax for complex data structures was never clean enough that I could remember it from session to session. The python for getting a hash of arrays (in Perlspeak):
Perl made it possible, but Python made it easy. What about returning complex objects from functions? [1]
Again, you can do that in Perl, but it was never anywhere near that easy. I've read and written lots of Perl in my day that was well-organized and well-written, but there are certain basic operations that are just inherently ugly. Those warts simple can't be made readable because of the relatively bizarre syntax required to create them.
[1] Yes, I realize that Slashdot's broken "ecode" tags don't exactly help my case regarding Python's readability.
Re:Buzzkill (Score:3, Insightful)
This is exactly right. Perl doesn't force (or even encourage) you to write code in any particular style; it gives you a great deal of flexibility. If you want to write good clean maintainable code, you can; if you want to write something that looks like my sig, you can. The strict pragma will add certain restrictions to prevent you from doing particularly awful things (like not declaring your variables and not quoting your strings), but it's really up to you how you want to write your code.
Re:Best Practice (Score:3, Insightful)
Re:This holds true (Score:4, Insightful)
Perl's syntax is very complex and it has a lot of operators. Most people don't know all of Perl's syntax, they only know a subset. However, each person knows a different subset of the language, so if you try to read code written by someone else who knows parts of the syntax you haven't learned yet, it won't make sense and you may not even be able to look it up in a reference to figure out what's going - it's easy to look up functions, but if you don't know what @foo[5..10] means, you may not know where to find out.
Re:Best Practice (Score:3, Insightful)
The problem with the program in question where I work is that it was poorly designed from the get-go. I can tell you for a fact that the vast majority of the program's run-time is in the single line that prints out a 512MB object to a file in human-readable format.
Languages are tools. You should use the tool that's best for the job, not because it matches the newest buzz-words.
Re:Best Best Practice: Don't Bloat Perl (Score:3, Insightful)
In other words, if all you know is the syntax, you don't know the language.
Re:Obligatory joke (Score:4, Insightful)
It's funny you bring it up, because here are my impressions of the book:
It's really quite a good book. There are probably only two or three things I actually disagree with Conway on, and for a book that takes stands, that's immense. He even convinced me on the "inside-out" class approach, which I scoffed at when I first heard about it.
The sad fact is, that if you follow all these practices, that's as good as Perl's going to get. And it's not very good. After using Ruby, or a good functional language, for a while, going back to Perl is like... well, it's not like visiting an old friend. It's like having to get back in your old jalopy because someone stole your "good" car.
By showing us how good Perl can be, Conway shows us the limit of its quality. Once upon a time, this would be an exciting lesson (I wrote programs in Perl almost exclusively for years, and loved it). But now, it just shows how much of a papering-over it needs to seem competent.
I like Ruby a lot. I like Erlang a lot. I wrote a lot of Python code on a huge project that used it exclusively; it has its charms, and is better than Perl, but its irritations as well ("char".join(array)? please). I'm not going to pick "the next big thing" except I will say that, for me at least, it's not Python.
Re:Use Python (Score:4, Insightful)
imho the power of python isnt the clear syntax, clear syntax can be written in perl too, some people are just too lazy to do it. python has really good threading and a nice oop model, perl's ithreads are still quite a mess and the variable & oop layer across it is even fuzzier and more difficult to bite through than the h4x0r'5 scripts
both languages are excellent for writing tiny helper tools for linux (tools that linux is missing a lot for dumb users), C and Java are both overkills for such simple tasks (a nice example of an overkill is a installer that is powered by a java gui, this is inhuman, uses twice the memory and need a bloating jvm to run). but without a really stable and "always being there" gui package these tools break a lot
i believe that perl is good in it's own key places, mostly being compact and very portable. in large and multithreaded applications ofcourse python rolls the house in the scripting world.
and for ruby fans, lets wait until the next version rolls out, then we may have a really good spot for that one too
use the right tool for the job and for the best practices use strict and warnings in perl, indent your code and avoid regexp hacks where you dont need them.