on September 12, 2006
This is a must-read for any Perl programmer. You are only as good as the teachers you have, and if your teachers use stuff like $|++, you are screwed. In this case, Conway would tell you to Use English;, and then you'd know what a $| is. A sampling of other tips:
Don't modify via $_ (too easy to screw things up)
Use hashes for arguments if arguments > 3 (trackability)
Use Croak instead of die (Croak gives more info, better for debugging)
Use ' ' instead of " " when no interpolation (less ambiguity)
Don't use unless (complication and confusion).
use /xms in regexes (for readability, and avoiding mistakes)
test when closing or opening a file
A few of the reviews here are 1 star. IMO these are people to which "freedom" is more important than "group code maintainability". This should really be the third Perl book for anybody, after Learning Perl and Intermediate Perl.
For those wanting to test their code against this book, there is a Perl Module, Perl::Critic, that does the job.
on August 2, 2005
I love this book, and I'm impressed with the guts it took to write it. Perl is a "there are many ways to do it" language, and Perl programmers are adamant about finding clever solutions in the language. This book sets down a set of guidelines for the most professional way to do it. And in so doing pays Perl a lot more respect than it's paid in other books.
I strongly recommend that anyone writing Perl professionally should read this. But I do have an issue or two with it. For example, I think it was wrong to start off with a rule about brackets. That's one thing that people are religious about and there is no real reason to go one way or another. That starts the book on a weak premise. From which it quickly recovers.
Overall, a fantastic book. Well written and researched. It's the kind of book I would expect from Damian Conway and I wasn't let down. A must-read for Perl programmers.
on August 3, 2005
What a great book. If you have experience programming in Perl you will truely appreciate the hard won insights of the author. As I read through the author's tips and guidelines for Perl programming I would constantly find myself thinking 'what a great idea' or 'why didn't I think of that'. We are always told in programming 'don't reinvent the wheel', as advice to find code already written to solve our problem. Well, with this book you can do something just as good regarding the learning process of Perl programming. Following the author's guidelines will save you countless hours by making you a better Perl programmer. I wish I had this book about 5 years ago, it would have improved my Perl programming ten fold. Better late than never.
on December 23, 2005
This book is probably one of the best tech books I've read. The topics he covers range quite a bit starting from the very beginning with programming style through documentation and error handline. Style is a contentious topic, if ever there was one, but he argues convincingly for each of the points he makes and gives practical reasons why it benefits you to code in a certain way. We've all heard many of these things before, but I've never been convinced that the particular way I coded was less good than any other proposed way - this book has changed my opinion on that.
He brings up so many topics, some well discussed and some more esoteric and presents practical benefits that almost anyone who reads it, I expect, will come away with some new habits. I think there are very few books I've ever read that could convince people to change their programming ways - years of developing versus a couple hours of reading. You may not agree with every point he makes, but he'll make you think about why you do certain things, and that can't but help make you a better programmer.
I can not recommend this book enough to any perl developer out there. If you're new to it or been doing it for years, this book is for you.
on January 3, 2007
Please allow me to be presumptuous and say that if you don't have this book and you're looking at buying it, stop waiting and just get it. As my bookshelf gets more and more full, this is one of those gems that I borrowed from my library, then went out and bought. Other reviewers have done an excellent job of detailing contents so I won't bore you with those.
The goal of this book is teaching Perl programmers how to write their code for both readability and maintainability. We've all been there - we wrote code months or years ago, or we're just picking up someone else's code and we need to go back in and change something. The challenge is, whether it's been a long time or it's someone else's code, it takes time to remember what we were trying to do. If we are inconsistent in our coding style, it can be difficult to switch to the style of the code we're working in.
Example: (quoting the book, p 453)
Don't be clever.
Tied variables are a clever idea, but "cleverness" is the
natural enemy of maintainable code. Unfortunately, Perl
provides endless opportunities for cleverness.
For example, imagine coming across this result selector in
| $optimal_result = [$result1=>$result2]->[$result2=>$result1];
This syntactic symmetry is very elegant, of course, and
devising it obviously provided the original developer with
a welcome diversion from the tedium of everyday coding. But
a clever line of code like that is a (recurring) nightmare
to understand and to maintain, and imposes an unnecessary
burden on everyone in the development and maintenance teams.
Cleverness doesn't have to be nearly that flagrant either.
Having finally deduced that the example expression returns
the smaller of the two results, you would almost certainly
be tempted to immediately replace it with something like
| $optimal_result = $result1 <= $result2 ? $result1 : $result2;
While that's certainly an improvement in both readability
and efficiency, it still requires some careful thought to
verify that it's doing the right (i.e., minimizing) thing.
And everyone who maintains this code will still have to
decode that expression--possibly every time they come
However, it's also possible to write that same expression
in a way that's so obvious, straightforward, and plain-
spoken that it requires no effort at all to verify that
it implements the desired behaviour:
| use List::Util qw( min );
| $optimal_result = min($result1, $result2);
It's not "clever" and it's even marginally slower, but
it is clean, clear, efficient, scalable, and easy to
maintain. And that's always a much better choice.
If you must rely on cleverness, encapsulate it.
If you never buy this book, at least go to your local library and check it out.
on May 31, 2006
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?
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:
1. Best Practices
2. Code Layout
3. Naming Conventions
4. Values and Expressions
6. Control Structures
8. Built-in Functions
12. Regular Expressions
13. Error Handling
14. Command-Line Processing
16. Class Hierarchies
18. Testing and Debugging
Suffice to say that Conway leaves no corner of Perl uncovered, offering well-reasoned and well-explained advice on improving your Perl code.
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 5. 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 4 stars.
on April 30, 2006
There is a problem that has troubled some of us (perhaps the ones, like me, coming from static languages) with Perl. On one side, we discover the inmense power of the language, that allows to do things not even conceivable before. However, we also discover later that the degree of "desorder" inside the programs tends to grow even faster than with traditional languages. Thus, while it is easy to develop fast, brilliant solutions, it becomes difficult to extend them (say 6 months later). One sometimes feels as if the power of the language "revolts" against the programmer. To be clear, this is not a new problem; the "desorder" (or "software enthropy") is a problem plaguing every system based on software, in any language (since the "Mythical Man Month"). But the dismay comes when one begins to suspect that Perl solves nothing in this area (or that it makes things worse).
Enter this book: under a very unpretentious title/subtitle ("practices/coding style"), Damian Conway attacks this problem from the first page to the last. He does so not by inflicting the reader with a new set of abstract theories (like you would expect from an University professor); rather, he proceeds bottom-up, examining every one of the language components - data structures, control mechanisms, filters, transforms, regular expressions, built-ins, objects, class hierarchies - analyzing the way that they are traditionally 'written' (literally!). The objective is to rewrite them in order to answer concrete questions:
1) which is the most clear way that this can be written, not only for the super smart programmer, but also for regular programmers who will come after?
2) can we write this algorithm in order to facilitate extensions, minimizing the possibility that errors will be introduced?
3) which form offers the least impact on other adjacent components? ("ecologically friendy" code).
4) which is the impact of the solutions for system performance (cpu, memory)? which solution is the best compromise when the above issues collide?
5) after having seen the "best home solution", is there a CPAN module already doing this? then, use it (if your envirnoment allows).
It is not even possible to cite the "best parts"; every subject and proposed solution is a gem of programming and design intelligence. Take for example the discussion on "Naming" (ch 3) or on "Unnecessary/Necessary Subscripting" (chapter 6); yes, they don't sound exciting, but just take the time to apply the reccomendations to existing code that you have (perhaps accessing nested data structures), and examine the result. For me, it was remarkable (Data::Alias is a gift!).
But let's come to the most controversial proposals (see angry comments in postings): pattern matching and objects.
1) Pattern Matching: the proposal is to generalize the usage of /\A ... \z/xms expression. After trying it for some time (on my most complex regexp program), my conclusions were the following: yes, the expressions were a bit more complex (several times, I had to introduce character classes not needed before). However, I noticed this: while before I had to decide (for every regexp) the subset of modifiers (/xms) to use and then "design" the expression based on this choice, now each expression was just designed for ONE (same) case, no questions asked. This was particularly useful when debugging or modifying: instead of running to the right of the expression to read the modifiers and then switch brain cells to read the expression accordingly, I knew inmediately how to interpret it. In short, there is a huge "simplification" bonus: '/xms' means (if each letter can be present or absent) 8 different combinations; unless each letter is always present, and then you have 1! The advantage (ease of maintenance/extension) largely exceeded the drawback (more care writing the regexp), for me.
2) Objects: they are implemented as "inside-out" objects; in short, an "object" is (rather, has) an identifier into a private database of attributes, each described by a hash. Thus, if you had a large collection of object instances, we go from a large multitude of "small bundles" (one hash per object) to a few large hashes (one per attribute). This desecration of the "object-bundle" produces this result: it is now impossible for clients to access the object internal data.
Notice how this goes against all what Perl authors have proudly said for years; that "Perl objects do not enforce privacy (unlike those other languages...), but rather they ask the client to respect the contract; too bad for the client if he does not". Instead, Damian Conway suspects the exact opposite scenario: if users of the class "break the contract", and months later the class designer modifies the class internals, guess who the "pointed-hairy boss" will blame? It is intriguing that this insight on how the real world works comes from an university professor; and he is completely right (I would add this: even when the boss is not unintelligent, the needs of the "existing applications" will prevail, by inertia laws; unless you have an extraordinary collection of personalities in your office).
But the advantages of the new implementation go much further than preventing political clashes; see the benefits for Inheritance (no collision of attribute names), and for complex Class Hierarchies. Even the eternal problem of constructors under Multiple Inheritance ("diamond" case) is solved: in one of the most memorable observations, the author exclaims (p.378): "the real problem is not that there aren't enough constructor calls; it's that there are too many!". A fantastic solution follows; you can love it from an architectural standpoint, and from a programming one (see ex 16-9, where the class' parents are ejected from the top of a list, while the grand-parents enter from the back; in a few lines, the whole hierarchy is collected, and the calls to "Builders" can be automated). Talk about "practices, and coding style"; this is Architecture, Design, and Programming at their best!
One last note for novice programmers: do not see this as a book only for advanced programmers; on the contrary, it is useful at all levels in Perl. Students of "Learning Perl" or "Intermediate Perl" should begin to read (in parallel) relevant chapters of this book, so that at the same time that you learn new areas and skills, you simultaneously "polish" them.
In fact, the book's lesson is: software "Enthropy" or "Desorder" must (and can) be fought systematically, from day 1, from the first line of code; it does not matter if it takes a bit more time; just do the right thing.
on April 25, 2006
This book is a treasure. I love perl and have 2 bookshelves filled with perl books. Most of them I looked through once - and then kept for reference. But this book (Perl Best Practices) somehow pulled me in - and I ended up reading every page of it. Why? Because I was finding elegant ways of writing the code. Note that I was writing Perl scripts every day for the last 10 years. So you would think I don't need instruction. Still after reading the PBP book, I am now doing many things differently.
Damian compares different styles of writing the code, explains potential problems (sometimes very subtle and difficult to catch), and explains how to write the code which is more readable and maintainable.
I highly recommend this book. Whether you are a newbee or a veteran - you will enjoy reading it.
on May 28, 2014
Perl is frequently criticized for being messy, hard to read, and unmaintainable... a complaint which is not without merit. Perl Best Practices is a direct response to that criticism, and goes a long way towards resolving those issues. Any team, or any individual for that matter, who is writing Perl code for a living should read this book and implement it's recommendations.
Perl is an extraordinarily flexible language, which by design puts as few constraints on the programmer as possible. This freedom lets it do amazing things, and is part of what makes Perl so powerful, but it is a double-edged sword. The fact that the language itself does not force you to conform to an arbitrary style of "good" programming means that the onus is on the programmer to be self-disciplined. Perl Best Practices (PBP) provides guidelines for that self-discipline, and the tool it inspired - perlcritic - provides an enforcement mechanism.
on July 15, 2007
Not only the best Perl book I've ever read, it's also one of the best programming language books, period.
If you've ever programmed C++ or Java, you'll know how revered the likes of Effective C++ and Effective Java are, a series of tips, suggestions, idioms, advice and commandments. This is the equivalent for Perl, except it's even more thorough and covers even more ground, from brace layout and statement formatting, to regexes, unit testing, documentation and command line parsing.
There's also an exceptionally good chapter on object orientation, wherein author Damian Conway guides the reader through the use of his own Class::Std module. If you're using objects in Perl, and you're still rolling your own, you're really making life unnecessarily difficult for yourself. Class::Std provides object features reminiscent of CLOS, and makes Perl competitive with the likes of Python and Ruby when it comes to objects. Class::Std has changed the way I code Perl forever, and I know I'm not the only one. Seriously, this chapter is worth the price of admission on it own.
It's hard to overstate just how much excellent stuff there is in here, there's even useful emacs and vi settings provided! And I've not even mentioned how well written it is. Damian Conway really does prove himself the master of witty examples.
Perl Best Practices is just brilliant. Absolutely essential reading - don't code Perl without it.