I wrote this book because I kept finding myself
telling my students, "I'm going to teach you how to program Perl well, but I'd have to teach you a lot more before you could take over a program that wasn't written well, and you wouldn't appreciate taking that much time away from learing how to write good programs of your own." So I've written a book to fill that need.
See Chapter 5 for more advice on avoiding scorn.
If you have the opportunity and the chutzpah, hand the program back to the developer who wote it, and as politely as you can, ask them to add use strict and use warnings (or -w) to the code, and let you have it back after they have fixed the code so it runs without errors or warnings. [...] This is not the time to tell them that doing this will almost certainly result in dozens of fatal errors, hundreds of warnings, and numerous changes required of the code in order to make it compliant with these new directives. They will think that your request is a trivial addition. Let them. The changes they make to enforce compliance will make your job immeasurably easier, because the way they choose to resolve each error or warning will be based on understanding of the code that they have and you do not. If you think this tactic is underhanded, you haven't yet tried to maintain a significant body of code that was developed without use strict and use warnings. After doing that, you'll be inclined to approve of far more stringent forms of punishment for a developer who omits them. The rack, for instance.
Remember that it is the norm for programs to grow by evolution and accretion. The more successful the program was, the more likely it is to have had other functionalty grafted onto it in response to requirements creep. Don't spend a long time trying to figure out the design rationale of a program; there may not be one left.
There are more.
This should give a flavor of the book.
It's a very nice flavor indeed.
-scott
