Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Web Development

Perl Medic: Optimizing Legacy Code


May, 2004: Perl Medic: Optimizing Legacy Code

Jack J. Woehr is an independent consultant and team mentor practicing in Colorado. He can be contacted at http://www.softwoehr.com.


Perl Medic: Optimizing Legacy Code
Peter J. Scott
Addison-Wesley, 2004
336 pp, $34.99
ISBN 0-201-79526-4

The subtitle of Perl Medic, "Optimizing Legacy Code," sounds like bizspeak. A more nerdly description of this book might be, "Maintaining Perl code whether it's written by you or others and whether or not it was designed to be maintained." Apropos the latter, author Peter J. Scott is cheerfully free to suggest the classic solution—a total rewrite—where appropriate. That, by itself, would have made a very short book and an even shorter review. Luckily for us, there are many more solutions and development patterns to discuss regarding Perl maintenance. Perl Medic's target audience begins at the level of intermediate Perl programmers who have been "working with Perl long enough to have heard terms like scalar, array, and hash," but reaches well beyond that entry level.

In many cases, the patient, a sick or dying Perl corpus, can be saved. One half of the value in Perl Medic is in the diagnostic and remedial techniques Scott provides. The residual value of the book are found in the practices that make your Perl code more maintainable. Maintainability strategies for Perl code have sometimes been obscure, even to experienced Perl programmers. It's been a hair-raising roller-coaster ride watching the language develop. The degree of cult participation traditionally necessary to stay on top of trends that could unexpectedly invalidate a seemingly reasonable application lifecycle taxes the patience of working developers. Scott offers the reader a compendium of what one might call "simplest-best" practices that are easily followed.

In the first four chapters, after introducing his subject and offering a few practical tips for achieving handover in some other fashion than having the code dumped onto your disk, Scott starts off reasonably enough by examining the use of Perl warnings.He continues with forensic techniques for evaluating the code and your tasks in taking up the code. Then testing is introduced, right where it should be, at the point before you start modifying code. Next comes the actual labor of rewriting code, beginning from style and variable names—in no other language than Forth do variable names seem to matter so much as in Perl—and concluding with antipatterns and the ongoing evolution of the code.

In the fifth and sixth chapters, the book moves on to issues of discipline, cognition, and semantics (or so I would characterize it) with an overarching theme of knowing why you are coding the way you are coding, why you are following certain patterns, and how to recognize code that follows blindly misunderstood or only partially grasped patterns. Then there's a complete chapter on upgrading, covering Perl 4 and 12 earlier releases of Perl 5 to Perl 5.8.3, the latter being the stable version used in the book, followed by chapters on CPAN and the use of modules—other people's and your own.

In Chapter 9, the books returns to forensics: static analysis, superfluous code, inefficient code, and debugging. Chapter 10 deals with robustness and Chapter 11 is a case study. There follows a brief wrap-up, which concludes with the sage (albeit utterly self-evident) warning that, "One day your code, too, will be inherited by someone else."

This is really a working programmer's book. Section 4.10 casts an interesting light on this point. In it, the author introduces a pithy and sometimes witty several-pages-long list of steps and considerations in program evolution, after begging off from expanding on each of these points on grounds of time and space. As they say in the East, "The good horse runs at the shadow of the whip." While Scott wriggles himself out from under the onus of spelling everything out, he concomitantly liberates the reader from having to slog through a bog of minutiae. It's the sort of bullet-list help a busy senior developer in the next cubicle might e-mail you in response to a very broad and general question. The subtext in both situations is, "If you're good enough to do this sort of work, this is all the help you need." Serendipity!

Perl Medic is a cute little book with the flavor of a 1980's programming language tome. Each chapter is introduced by a relevant (or occasionally irrelevant) quote and a cartoon à la Leo Brodie. Some of the quotations are rather apt: My favorite is Chapter 2's quote from Henrik Ibsen about how one's outlook may be haunted by the ghosts of "dead ideas and lifeless old beliefs," a concept many team programmers will greet with a sigh of recognition. Scott has a sharp eye for fluff and ambiguity. He communicates his insights in a "teach a man to fish" fashion that is equally rewarding to the reader, whether that reader is immersed in a chapter or browsing a paragraph for tips. The writing is colloquial and intimate and exhibits very little dependency between chapters, making this an open-anywhere book. The publication production quality is high, and the book is gratifyingly well indexed.

The book's web site is http://www.perlmedic.com/, where you can download the files that accompany the book after you answer a question about the book. Or, if you're tired of reading, you can click on links for the author's consulting services.

TPJ


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.