Slashdot Mirror
Perl Medic
One of the goals of Perl Medic is to transform code from stylistically poor and unmaintainable into stylistically sound, maintainable and testable code. The format of Perl Medic is very similar to books like The Pragmatic Programmer or The Practice of Programming. Perl Medic shows the reader best practices by example. Some of the chapters are checklists of practices that will help improve your ability to manage and wrangle the code, while others are lists of patterns and practices you should avoid, and should replace with the examples provided. This format very readable, and provides an excellent forum for gleaning what ways to improve the code.
Perl Medic is designed with experienced coders in mind. Topics are presented as if the reader may be using these ideas already in their code, whether good or not. While the advice is good, the presentation may be confusing for beginner and intermediate programmers who aren't intimately familiar with the concepts. I found myself re-reading several topics to try and grasp what the author was trying to convey. After several readings of the section on test harnesses, I still needed help, and ran to the Perl documentation to better understand what the author was saying. Certain advice is also presented, only to have it countered in the next section. Most Perl programmers are familiar with the '-w' switch, which turns on warnings in a Perl program. The pragma 'use warnings' is introduced as a way to turn on warnings for just the code being worked on without displaying the warnings of the modules included in the program. In the next section, the author points out that it might be a good idea to put '-w' in there to see if there are any issues in the modules you may be including. While this advice may be intuitive for experienced Perl coders, the beginner may be confused. "Should I use '-w', or should I use 'use warnings'" she may ask herself.
The book also suffers from a case of being too brief in some sections. In section 2.3.1 (Gobbledygook) the reader is directed for help on how to turn a partially obfuscated program into more intelligible code; a very useful skill indeed. The author redirects the reader to section 4.5 where the utility perltidy is discussed with further detail, but before ending the section, the author also introduces the module 'B::Deobfuscate' along with a URL. No mention of how to use it is provided. In section 6.4 (Debugging Strategies) the author gives advice on how to debug a program. His advice: "Divide and Conquer". While there is debugging advice throughout the book, it's a little frustrating to see a section specifically designated "Debugging", with only one subheading under it. The organization of some of the topics feels artificial, and perhaps should be reorganized in future editions.
Underneath these faults, though, Perl Medic is a great book. Chapter 11 (A Case Study) should be required reading for coders inheriting Perl projects. This chapter is a blow-by-blow account of the author's work in transforming a simple LDAP application from Perl 4 into a robust Perl 5.8 application. The author is very candid about what decisions were made in the code transformation, and why certain elements were addressed in the way they were addressed. One particular element is an elderly module used for the LDAP lookups themselves. The author details the process used to determine a better module to replace this module, and guides the reader through each of the steps required to change the code to use this new module. The decisions the author uses to make this code work under the new environment are enlightening for anyone planning a migration of Perl code into a newer environment. Chapter 7 contains the versions of Perl from Perl 4 up until 5.8.3, and elaborates on what changed between the versions (very helpful for those who are planning an upgrade from 5.003 to a more recent version of Perl). Chapter 9 (Analysis) has very useful tips for not only debugging you program, but for using the Perl Debugger and getting the most out of your debugging session.
Perl Medic is recommended for anyone who is tasked with maintaining or writing Perl Code. While the examples are written with experienced coders in mind, beginners will do well to use this book for areas to focus on while they learn the language. Inheriting code can be a daunting task, but with a book like Perl Medic, you'll have the tools at hand to help ease the work ahead into a more manageable task. And you'll make it easier for "the next guy".
You can purchase Perl Medic: Transforming Legacy Code from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Preventative and maintainance coding is difficult enough when a language has a particular idiom you can follow. Perl gives you an unparallelled freedom of expression and with it several confusingly different ways to achieve the same task.
I used to be a believer, but now it seems Python is ready to take the yoke, at least with those of us who wonder how can you build a complex yet maintainable script without static typing.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
In most cases, refreshing an existing program will take less time than rewriting it in a diffferent language, as in both cases you need to have a firm understanding of what the program does before proceeding.
In many corporate cases, you don't have the luxury of writing in any language you please and, even if you do, in most cases you'll have an uphill challenge convincing a PHB that rewriting from scratch in a new language is the better proposition.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
Cue the flood of 'Perl is hard to maintain/read' and counterflood of 'You can write hard to maintain/read code in any language' posts.
I think it can be generally agreed that due to the TMTOWTDI philosophy behind Perl, there can be complications involved when inheriting code from others who use a different style and different approach. (Obviously due to the many ways any given task can be approached).
One (common?) approach to dealing with this seems to be to use different languages such as Python or Ruby. Arguably, however, if more coders stuck to code style guidelines and used best practices instead of quick hacks, the problem would be minimal, or at least no worse than other scripting languages.
Business Voyeur
on what test? Take a fairly common task - word counting
Perl 1.0 cpu time 11 lines of code.
gcc 0.3 cpu time 182 lines of code.
So i can distort reality also and say while C can sometimes be as fast as 3 times faster it will take 1700% more lines of code.
Baloney. The advantage of Perl is that you have the option to write maintainably if you want to!
If I just need a quick solution to a problem, I can very quickly write gibberish that does the job and then forget about it.
If I'm writing a big app which someone will inherit from me, I can avoid confusing constructs for something easier to follow. I can pass variables in Perl style, C-style, I can use objects if I want. Whatever I think will be most maintainable for somebody else.
Just because you can write gibberish in Perl doesn't mean you can't write good stuff too.
PHP? Are you kidding me? There is nothing worse than PHP. PHP looks strewn together without thought. Just consider the system by which PHP's built-in functions are named. Except that there is no such system; the names follow all sorts of different casing rules.
PHP was made by taking a cute language for embedding a broken imitation of Perl-esque syntax in-between HTML and extending it with bajillions of functions that badly needed to be namespaced. It never provided anything useful that Perl couldn't, except that it made newbies comfortable by making them feel like they're in "HTML land" instead of "Programming language land."
Yeah, but perl makes it easier to write shit. I happen to love perl and use it all the time, but I also have to be very disciplined about the aspects and particularly syntax conventions of the language that I use, in order to write readable perl. Just because you can write:
do { thirty(); things(); in(); a(); list(); unformatted(); } if($foo);
Doesn't mean that you should.
One of the brilliant aspects of perl is that it allows you to write code like you think about code. Well doesn't that presuppose that other people are going to think about code the same way you do? Ooops.
Books and books have been written on the need for code formatting, syntax, and variable naming conventions in languages that are twice as rigorous and disciplined as perl. In perl, the need is double.
So I guess what I'm saying is that although shitty code is shitty code in any language, perl provides the possibility for a certain depth and richness of shit that just isn't accomodated in other languages. Kudos to the authors for addressing what is a real problem with a powerful and widely used programming language.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
s/shitty perl code/shitty code in any language/;
You can inherit shit in any language.
That is true, but perl does provide easy ways to write sloppy or unmaintainable code. That's not necessarily a bad thing, because it is exactly that looseness that makes perl a very fast language to develop quick scripts in - there aren't anywhere near as many hoops to jump through and TIMTOWTDI makes it very easy to just write whatever you're thinking. For the niche of a language that lets you knock together something to do the job quickly perl is fine.
If you want anything maintainable you need to forget all of that and make use strict and use warnings mandatory, and enforce some coding style standards. That can be done, and if you do that it is easy enough to write maintainable perl - it's just that you can't expect the language to help you with it much: you have to enforce and police the standards yourself.
Jedidiah.
Craft Beer Programming T-shirts
Where I work, use of $_ in any form is punishable by death. If you use it in the implied form, you get tortured first.
I hate the language for its utter lack of consistency. People talk about how great the php.net documentation is but I think they have the causality reversed: those docs have to be excellent or the language would be unnavigable. I have no desire to remember 3500 core language functions with similar (but inconsistent) naming systems and a randomized argument list. Seriously, what were they thinking?
I don't think PHP is inherently bad, but the current implementation certainly is.
Dewey, what part of this looks like authorities should be involved?
Sometimes the developer's time is more important that the computer's time.
Having written code in Perl and other languages (COBOL, C++, Java, VB, TCL), I have come to the conclusion that Perl as a language is more concerned with being clever than getting the job done. The language has some of the most untechnical keywords (e.g. bless, chomp and others) and it makes it completely laughable (like a toy almost). Also, just look at any of the books and or documention written about perl. They all read like Tom Baker scripts from the 1970s Dr. Who episodes.
While the TIMTOWTDI philosophy of perl is cute in theory, it seems to have backlashed and its now total anarchy. I look at some perl and it's total alphabet soup. And the lame excuse of "just because you can do it this way doesn't mean you should" is like putting warnings on cigarette boxes (just because you can smoke these doesn't mean you should).
This book is not going to save perl. It's way too late for that. Perl will continue to be written poorly by people who think they're smarter than everyone else and will try to write their code to read like Tolstoy rather than for what it is.
GOBACK.