A Book Review of Effective Perl Programming Ways to Write Better; More Idiomatic Perl
Buy it now
One Minute Bottom Line
|Not for the person looking to learn Perl, but a must read for those looking to improve their Perling skills. At the risk of using a bad cliché and pun this book is filled with pearls of wisdom from people who obviously know their subject well. In my opinion if it prevents one bug it will have paid for itself.|
ReviewI read this book because I am starting a devops project to automate my project setup (i.e. creating databases, users, web space, source code repositories, setting up Google analytics etc.). Perl’s portability and power make this a good fit. Since these project components are distributed across several machines and operating systems.
I have worked with several Perl programmers that seemed to think that the epitome of Perl programming was an unreadable several hundred byte Perl one liner. One liners that no one else could read, or would dare modify. I was a little concerned that I would find the same in this book; I shouldn’t have worried. The first examples quickly dispelled this concern. In every case the authors have erred on the side of readability over code brevity. I think the authors may have worked with some of the same programmers I have, since Perl one liners is left until the very end.
What this book does deliver is 120 well-reasoned, logical and clear suggestions, and examples of, good Perl code and coding practices. The authors have done a very good job explaining the Perl internals to as they say illuminate the “dark places in Perl (e.g. example 43 the difference between my and local). I especially appreciated these discussions where an incomplete understanding could lead to the type of code that produces inconsistent results (e.g. example 10 Don’t assign undef when you want an empty array), and as a result can be a nightmare to debug. The authors have also done an excellent job of providing pragmatic advice and avoiding the holy wars (e.g. example 111 on Perl ::Tidy) quietly shows two different brace styles and let you decide which is correct for yourself. The author’s obvious effort to avoid these issues made the book’s examples not only much clearer but made it easier to use this book as a group training tool.
Organization is one of the books strengths and at the same time it’s biggest weakness. Because each chapter is broken up into several self-contained yet related examples (e.g. examples 72-78 make up the chapter on Unicode) it makes the book very easy to pick up and read. You can read one or two examples at a time rather than an entire chapter. It also makes it easy to use a reference guide when coding (something the author’s mentioned they did with the first edition and have succeeded in doing with this edition). However, I found the order and placement of a couple of chapters a little odd. The chapters that deal with CPAN and Distribution are separated by the chapter on Unicode. Likewise they come before the chapter on Testing. I think putting these two chapters together and moving them to the end of the book (or even before the last chapter “Miscellany” would have made more sense. This may not be an issue when using this as a reference while coding where you will refer to only a single example or small group of examples, but would have made it much easier for those of us who read the book front to back.
I also have a minor nit to pick with the title of the last Chapter “Miscellany.” While I understand the Author’s argument that it is a collection of all the examples that didn’t fit elsewhere. I agree with Uncle Bob among others who have argued that one of the most important things we as programmers do is name things, and as such we should work very hard at naming them well. In terms of a forming a mental model when looking for an example from the book miscellany doesn’t help much.
This is a not a book for Perl beginners; it will not teach you Perl. However, if you already know Perl and implement the books examples, it can and will make you a better more proficient Perler.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)