Perl Medic: Maintaining Inherited Code [Paperback]

A quote on the front cover of this book says "if you code in Perl then youneed to read this book". That's a pretty bold claim to make. It made methink of the hyperbole on covers of books that claim to teach you toprogram in Perl in just a few days. But this book is published by AddisonWesley, who are a well respected technical publisher of technical booksand the quote is from Adam Turoff who certainly knows what he's talkingabout when it comes to Perl programming. So in this case the claim isn'thyperbole. The book really is one that I want every Perl programmer toread.
Perl gets a lot of bad press from people who claim that it encouragespeople to write unreadable code. Whilst there's certainly a lot of verybad Perl code out there I think that's more a sign that it's used by a lotof people who don't know how to program than a reflection on the languageitself. And that's where this book comes in. It assumes that you arefamiliar with the syntax of Perl but that you've never really been shownhow to use it effectively. Which is a situation that many Perl programmersfind themselves in.
Perl Medic is actually targetted at people who have to maintain older Perlcode written by someone else, but I think that the information it containsis just as useful to anyone coding in Perl. Peter Scott has a lot ofexperience in writing Perl and in training other people to write Perl andthe distillation of that experience and knowledge into these 300-odd pagesmean that there are few Perl programmers who won't pick up somethinguseful from this book.
The main emphasis in the book is on increasing the maintainability ofcode. The techniques are wide-ranging. I particularly enjoyed the examplesof refactoring programs and the coverage of using modules from CPAN. Twoother very good sections are the one on antipatterns in chapter 4 and theone on cargo cult programming in chapter 6. Together these sections give aprogrammer a number of easy to recognise quick wins when improvingexisting code and a checklist of things not to do when writing newcode.
There are a couple of niggles. I've already mentioned that I think thebook has been slightly mis-targetted and that it should have been aimed atanyone writing Perl code. The other problem that I had was that the medicanalogy that runs through the book gets a bit strained at times. But theseare only minor and they shouldn't prevent you from adding this book toyour library.
In fact, all in all, the quote on the front cover is pretty accurate.

Like author Peter Scott's previous book (co-written with Ed Wright), Perl Debugged, Perl Medic is rather inaccurately titled. Both books are collections of advice and tips on best practices and idioms in Perl, like Effective Perl Programming and Perl Best Practices. You can think of Perl Medic as a sequel to Perl Debugged. You definitely don't need to have read the former, but if you have, you should have a good idea about the format and contents you can expect here.

There is more advice on code style, low-level stuff like brace indentation and choosing decent variable names. Additionally, tracing, profiling, benchmarking and logging are again introduced. Some of this is admittedly rather reminiscent of what appeared in Perl Debugged. Happily, also present is the clear writing, which is informal without ever talking down to the reader.

Perl Medic, however, has a more agile flavour than Perl Debugged. Again, there is a chapter on unit testing, but it's much more fleshed out in this book, featuring far more modules, and providing an entire Test Driven Development example of a bounds-checked array.

Also, some refactorings are introduced, such as inlining temporary variables and extracting subroutines. The final chapter of the book is a refactoring example on some ancient Perl 4 cgi code, that pulls together most of the themes of the book.

There's also an in-depth discussion of what the strict and warnings pragmas entail, beyond that provided by most books. Also worthy of note is the chapter on 'cargo cult' Perl, where the author's pet peeves about non-idiomatic Perl code are explored, from practices which are merely pointless to the downright wrong.

Much of this material is general good practice. However, there are some chapters that help to justify the 'legacy code' approach. Chapter 7 provides a potted history of the different versions of Perl from Perl 4 onwards, and how to spot which version a program was targetted at. There is some mention of legacy code in the unit testing chapter, but not much.

In general, I think a lot of the suggestions will be obvious to anyone with experience with Perl, or experience with another modern programming language: use new modules from CPAN where you can, use lexically scoped (my) variables and localise global access and, of course, turn on strict and warnings. Overall, I wasn't much convinced with the 'legacy code' aspect of the book and the strained medical metaphor renders many of the chapter names nonsensical.

Another slight problem I had is that, like Perl Debugged, there can be a lack of flow between (and sometimes within) chapters. Chapter 10, nominally about maintainability, starts with assertions and Eiffel-style contract programming, and then goes onto logging, tieing, overloading, POD and version control integration. It's hard to see this as a cohesive whole.

If you're looking for a book on dealing with legacy code, Michael Feathers' Working Effectively with Legacy Code provides more bang for your buck -- although it's not Perl-specific (in fact, I'm pretty sure there's no Perl code in it at all). However, if you're a budding agilist looking for Perl-based examples of refactoring and TDD, then this is a good choice. Less experienced Perl programmers should definitely consider this, especially alongside Perl Debugged, as it provides both a good grounding in best practices, and more advanced development skills such as profiling and code coverage.