This a great manual. Instead of being a reference like most books that you may only need parts of, every chapter has some interesting information and is applicable to daily coding. Since at this point you can learn a lot of Perl just on Google, textbook style manuals are on the way out. Best practices, though, is still very applicable. I wish I had read this book years ago looking back at my functional but awkward scripts.

One of the biggest asset in the Perl community is the people that form it. And Damien Conway is one of its outstanding members. Possibly the best speaker I've ever seen, he injects wisdom and wit in its books, which always take you a bit further in the path of Perl Enlightment. This one, of course, is no exception. Not only it teaches what you should do, but the many things you _shoulnd't_ do.
When will we be seeing a novel by Damien Conway? Don't let Charles Stross be the only perl monger that writes novels!

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.

This is a fantastic book that's valuable no matter what language you
program in. I've been writing code for three decades and have
programmed in almost two dozen languages and the priorities are always
the same when writing / reviewing code: maintainability, efficiency and
robustness. Every dictum in this book clearly advances one or more of
these priorities. If you're like me, you'll wish you had this book when
you started your software engineering career.

For development teams, this book is an instant win. With any
development team, there is always a discussion as to what coding
standards to use. Perl BP can be used to short-circuit such debate, to
the benefit of everyone involved.

Of course, not everyone will be happy with the standards outlined in the
book. Before I plunged in, I skimmed through the book and found things
that I disagreed with: K&R braces; loop labeling; no unless statements;
postfix if; etc. The arguments made in the book, however, are so
compelling that I'm now gladly writing my code to conform with them.

I always feel fortunate when I read a book that makes me want to change
my behavior for the better. Perl BP is one of these books.

This is the best collection of good ideas to make your life easier as you maintain your code and others code. I'm in Software Configuration Management, and I have to help people pickup others code all the time. If everyone in my shop used these practices, my job would be much simpler. Get it.

Software development is all about making choices -- What do I name this variable? Where do I put that curly brace? Should I use a function or an object? -- and the flexibility of Perl offers us even more choices than most other languages.

Yet we programmers don't always understand why we make those choices -- Is it because it has worked before? Or is it because I saw someone else do it? Did I read it in a book? Or maybe I've just never really thought about it.

In "Perl Best Practices", Damian Conway explains exactly how and why he makes his software development choices. Even if you don't agree with some of Conway's guidelines, reading PBP will force you to explain your own choices to yourself.

By reading "Perl Best Practices", you will gain a deeper understanding of Perl and sharpen your sense of "code smell." You'll find yourself frequently asking "Is there a better way to do this?"

I was so impressed by "Perl Best Practices" that I created Perl::Critic, which is a static source code analyzer based on Conway's book. With Perl::Critic, you can instantly check if you code meets Conway's guidelines from "Perl Best Practices." Perl::Critic is available from CPAN.

Talks about many topics. Some are at my level of comprehension, other are too technical for me. Some chapters are really very interesting, other less (typical consideration on a book that writes about so many different topics).
I strongly suggest to read this book, it makes you aware of many good practices and ideas.

Talks about many topics. Some are at my level of comprehension, other are too technical for me. Some chapters are really very interesting, other less (typical consideration on a book that writes about so many different topics).
I strongly suggest to read this book, it makes you aware of many good practices and ideas.

I don't exactly work on a programming team, but as they say, any program involves at least a team of two--me, and me 6 months (more like 3 weeks) later, it saves LOTS of time to have a code that's easy to debug and maintain. Now that I've got this book, I wish I had had this book when I started with Learning Perl (or, rather, when I had started with programming). It feels like having a very experienced buddy right by me, sharing with me all the neat little tricks and giving out sound advices re programming. I had the tendency to write terse codes, which had led to a personal record of spending 2 weeks debugging/verifying a short TrueBasic code that had no bug in it. This books saved me from falling back there ever gain. A must have if you program (in Perl) regularly.

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)

Cleverness
----
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
production code:

| $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
the following:

| $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
across it.

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.

Encapsulated Cleverness
---
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.

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)

Cleverness
----
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
production code:

| $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
the following:

| $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
across it.

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.

Encapsulated Cleverness
---
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.

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).


A few of the reviews here are 1 star. IMO these are people to which "freedom" is more important than "group code maintanability". 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.

I came to Perl from C. Some of the good things I learnt in C (using K&R coding style), and some of the bad things, were both dealt with in this book.

This book however provides the basis for developing a coherent style framework, and avoids many of the more esoteric perl idioms that have you hunting through the manual any time you see them.

As a result of reading this book, I have revised a number of my coding practices, some of which I've learnt from looking at other people's code.

I have been pleasently surprised at the positive impact this is now having on the amount of time I'm spending updating older code.

Very well worth the money.

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
5. Variables
6. Control Structures
7. Documentation
8. Built-in Functions
9. Subroutines
10. I/O
11. References
12. Regular Expressions
13. Error Handling
14. Command-Line Processing
15. Objects
16. Class Hierarchies
17. Modules
18. Testing and Debugging
19. Miscellanea

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.

"Perl Best Practices" provides a good tour of the current features of
Perl 5.8.x and sheds light on all the corners of the language except
one. I didn't understand why there is no info on Win32 Perl (use
"chomp" instead of "chop", stuff like that). The book would have been
better if it hadn't shied away from that. It seems like Conway
decided to leave OS-specific best practices for another book. Apart
from that one gripe the book is quite good and will force the reader
to think about ways to improve his programming even though no one will
agree with everything. The books strongest point is that it touches
on the oldest parts of the language and also some really new stuff
like importing Perl 6 behavior via CPAN modules, and ties it all
together into a coherent body of thought. The thing that really
shines is how much Conway understands how Perl works as a programming
language and is honest about where it's lacking. Apart from the
absence of any Win32 or other OS-specific content, this book is a
treasure and worth owning and referring to often.

I think it is very telling that all the reviews so far are 5 star or 1 star. The author clearly pushes some peoples buttons. You don't have to agree with every recommendation made, but a lot can be learned from the discussion of each topic. It's rare for me to read a technical book cover-to-cover, but I did with this book and enjoyed it. I've started reading some sections again.

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.

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 realizes that Perl solves nothing in this area (or even 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 hierachies - analyzing the way that they are traditionally 'written' (literally!). The objective is 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? which form offers the least impact on other adjacent components? ("ecologically friendy" code).
3) which is the impact of the solutions for system performance (cpu, memory)? which solution is the best compromise when the above issues collide?
4) 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 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. A bit perplexing at first. 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) 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 user to respect the contract; too bad for the user 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; but 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.

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.

Three observations about PBP

PBP tells you how to write good Perl until you have enough experience to know better. Then you'll write Perl like the book suggests because you do know better.

PBP is like "use strict". At first using each seems overbearing and painful, after awhile you wonder how you endured the pain of not using them.

PBP describes programming habits that, if followed, will make your programming time more productive. It will also make it more enjoyable, unless you actually like beating your head against the wall searching for self-introduced bugs.

Writing s{ ,\z }{}xms when you mean s/,$// (as suggested in this book) is borderline idiocy. If I wanted to be needlessly verbose, I would have written it in Java. s/,$// is concise and works in sed and vi too.

Damian's beautifully written, practical. Perl guide of 256 clean Perl examples is certainly useful for experienced professionals. But as a University Professor of Computer Science I would like to focus on its value to help relative novices develop outstanding Perl technique from the start.

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.

This book will not help you write better code. It is filled with useless tips like "ALWAYS CALL SUBROUTINES WITH PARENTHESES" and "ALWAYS RETURN VIA AN EXPLICIT RETURN". How silly! Stick to the advice found in Programming Perl (aka the Perl Bible).

You can't really go wrong with this one, excellent for the beginner to moderately advanced perl programmer. Your milage may vary if you've been working with Perl long enough to have acquired the habits detailed within as a matter of natural course but it is still a great reference. The structure of the book is very clear and clean - no wading through overly long winded sections to find what you're interested in. You might find yourself disagreeing with a few of the points but the greatest portion of the book is filled with solid, good sense advice. Particularly appealing are the explanations accompanying the guidelines that often give interesting insight in to the 'why' of doing things a certain way. I wish I had had this book six years ago but I would still recommend it to even the most experienced perl coder.

This is a landmark book intended for existing Perl programmers who seek to write high quality, maintainable Perl 5 software. It explains how to avoid all-to-common idiosyncratic, flaky code; logical, performance, and semantic pitfalls; confusing or inconsistent practices; and reinventing the wheel. The book would particularly suit a team of Perl programmers to get everyone on the same page and avoid tripping over the same problems again and again.

Authored by one of the main minds behind Perl, the book is written in a highly intelligent, concise, and engaging style well suited for both the general audience and advanced reader--in a way that makes the book unique. Though it is best to read the book in a linear fashion, chapters and sections can, in many cases, be consulted in random order.

The style guidelines are reasonably mainstream, uniquely Perl, and workable in practice. There are some diversions from the mainstream, for Perl sometimes has no mainstream or is a cargo cult, which is a problem the book seeks to address. Such cases are generally identified and the alternatives convincingly argued, but you are free to choose otherwise and still learn much from this book. More than a few times, the recommendation given (e.g. to object orientation or versioning) is to use one of Damian's many particular CPAN modules, which I suspect may be too Damian-ized or unproven, yet always interesting and worth consideration as we look ahead toward Perl 6. The book will definitely change the way I write and think about Perl.

Well, here's an example that it's not necessarily the loftiness of the subject matter that determines the quality or usefulness of a technical book. This one only deals with "Best Practices", a collection of guidelines, which might lead one to think it can't be all that big a deal.

But, boy was I impressed (in fact so impressed that I'm writing my first ever book review! ). In my mind, this book is up there with Larry Wall's Programming Perl in terms of sheer insight and utility. You can tell the author knows his stuff. His programming wisdom and smarts show through in every subject he touches, and the breadth of subjects is comprehensive. Equally as important, it is a very *very* well written and proof-read book. In the 90% or so of the book I've read, I haven't run accross a single lame, half hearted or incoherent coverage, or even a sentence for that matter. I'm not sure whether I've even seen so much as a typo. Everything is presented in a concise, down to earth, to-the-point manner, with occasional spices of background insight mixed in. Nary a sentence feels out of place. It just goes to show how well a technical book(even a light weight one at that) can be written. It's a far cry from all those trashy books out there! I just wish there were books like this for the other languages as well, like Python, Ruby, and Tcl/TK. Sadly, there rarely are.

If you're an experienced Perl programmer, my advice is: get the book, digest it and follow all the best practice guidelines in it. It will make your programs so much the better.
If you're not so experienced, this book may not be so useful to you as yet, but you'll in due course graduate to it.

Thanks Damien for this great book. I sure learned a lot from it.

Perl Best Practices is a book of standards and styles that if followed produce code that is much easier to maintain. In total it contains 256 guidelines for coding, layout, name selection, program decomposition, modularity, error handling, testing, and debugging among many others. The section on code formatting is extremely useful and follows the conventions taught in most degree programs in programming. If it is followed exactly then it is much easier to understand the program and what each section is doing nine months later when you have to change something and can't remember the purpose of many of the code lines. This, of course, makes the code much easier to maintain and allows the assignment of programming different sections to other people. The author ends the book with several very useful appendixes including one that lists most of the more useful modules and utilities available for Perl. Perl Best Practices is highly recommended for all Perl Programmers but especially so for new ones or ones who need to set a standard for coding.

This book contains a tremendous amount of information that will help make you (and me) a better Perl programmer. Obviously, there are many ways to do things in Perl, but it does help to have a guide to show the different ways and why one way might be better than another - as far as maintenance, readability, etc.

For Perl to be taken more seriously as a structured, modular, maintainable language, we need to start using more discipline in implementing style suggestions such as those contained in this book.

I would definately recommend this book to anyone who uses Perl. It will be useful at some level to all developers. It might also be useful for those who don't use Perl, but believe that Perl is "so much line noise" and to know that it doesn't have to look that cryptic.

I was a bit skeptical of this book. I expected one of those books that tries to get you to program based on arbitrary theological arguments from the author. After a friend (*cough* Randal *cough*) recommended the book to me, I want out and bought it.

This book gives you examples of coding style and technique, as well as the reasons as to why you want to do it that way.

You may not use all of the techniques in the book, but you will definitly learn something from it.

If you want to become a better perl programmer, this is one of the best books to buy.

It's almost a certainty that you won't like all of the suggestions that follow if you're an experienced developer. Author Damian Conway has done an outstanding job of designing a book to help you write better Perl code.

Conway begins by explaining why it might be worth reassessing your current coding practices. Next, the author tackles the many contentious issues of code layout. Then, he presents a series of guidelines that can help you choose more descriptive name for variables, subroutines, and namespaces. Conway continues by providing a simple set of rules that can help you avoid common pitfalls when creating character strings, numbers, and lists. In addition, the author next explores a robust approach to using variables. He also examines Perl's rich variety of control structures, encouraging the use of those that are easier to maintain, less error-prone, or more efficient. The author next suggests a series of techniques that can make documenting your code less tedious, and therefore more likely. Next, the author discusses better ways of using some of Perl's most popular built-in functions, including sort, reveres, scalar, eval, unpack, split, substr, values, select, sleep, map and grep. Conway continues by describing efficient and maintainable ways to write subroutines in Perl, including the use of positional, named, and optional arguments; argument validation and defaults; safe calling and return conventions; predictable return values in various contexts; and, why subroutine prototypes and implicit returns should be avoided. Next, he explains how to open and close files reliably; when to use line-based input, how to correctly detect interactive applications; the importance of prompting ; and, how best to provide feedback to users during long non-interactive tasks. Then, he offers advice on demystifying Perl's many dereferencing syn-taxes; discusses why symbolic references create more problems than they solve; and, recommends ways to prevent cyclic reference chains from causing memory leaks. The author next presents guidelines for using regular expressions. Then, he advocates a coherent exception-based approach to error handling, and explains why exceptions are preferable to special return values or flags. Next, he addresses the design and implementation of command-line interfaces, both for individual programs and for application suites. Conway continues by offering a robust and efficient approach to creating objects and class hierarchies in Perl. Next, he looks at non-object-oriented modules; exploring the best ways to create them; design their interfaces; declare and check their version numbers; and, refacter existing code into them. Then, he encourages the use of testing, advocating test-driven design and development using the core Test:: modules. Finally, he offers several additional guidelines on miscellaneous topics such as revision control; interfacing to code written in other languages; processing configuration files; text formatting; tied variables; benchmarking and profiling your code; caching techniques; and, some general advice on refactoring.

With the preceding in mind, the author has done an excellent job of designing a book that produces Perl code that is clear, robust, efficient, maintainable, and concise. At the end of the day, the guidelines in this book, much like Perl itself, are about helping you get your job done, without getting in the way.