Most programmers write the first code that comes into their heads. It's pretty bad code. If you add a second phase, in which you edit the code, tighten it up, and trim out the unnecessary stuff, the result is much better. This book will teach you how to do that.
I have read a lot of Perl code in the last ten years or so. The most important thing I have learned is this: Most programs are horribly overwritten. They have 50 to 100% more code than they need. If you can recognize this extra wasted junk and remove it, you are left with a program that does the same thing in the same way but what is easier to debug, easier to read, and easier to maintain.
At this point in the explanation, about half the people I talk to say "oh, you just cut out all the comments!" Har har har. I am really tired of that joke.
No. Everyone agrees that cutting out the comments is not a benefit. Neither is cutting out the white space. Maybe people make this joke because they don't believe that their programs contain as much as 50% unnecessary garbage. But a lot of programs do contain that much junk.
And once you know the tricks, it is not hard to recognize the junk and it's not hard to remove it. I have identified perhaps 30 or 40 "red flags", which are easily-visible signs in the code that there might be an easy opportunity for a significant improvement. That is what the book is about.
For example, one red flag is a family of related scalars like $x1, $x2, $x3, and so on. (I want to interject a long explanation here of why this is a red flag, but I'd better save it for the book.) If you see this, you should pause and ask what would happen if you were to replace this family with an array @x. Usually the answer is that the resulting code would be somewhat simpler, more straightforward, more concise. Not concise because the whitespace has been removed—which is not concision at all; it's just stupid—but because the new code is doing the same thing in a simpler and more straightforward way.
After replacing $x1, $x2, $x3 with @x, you go on to the next thing. After you have corrected fifty of these little problems, and trimmed up the code by a line or two each time—and often there are fifty of these things to clean up—you find that the program is a hundred lines shorter than it was before, and a lot easier to understand.
My last book, Higher-Order Perl, was all about being as clever as I possibly could. The new book is just the opposite. While it might be true that you have to be very clever to write great code, I think that writing good code is within everyone's abilities. Everyone, including clever people, has off days. This book is about how to write good code even when you're hung over. Maybe the code that first comes out of your head on those days is pretty bad. But the point of the book is that you can make bad code better by fixing it up a little, and that it's not hard to learn to do that.
I have a lot more to say on the subject (or else I wouldn't be writing a book about it) so I'd better stop here.
The book is about two-thirds finished. As of 5 August 2006, I have 48,904 words written for 12 chapters, totalling about 150 pages. I have material gathered and detailed notes prepared for four more three more chapters that I haven't written.
The schedule for the book has me delivering the completed draft manuscript on 15 December 2006, and the final corrected manuscript on 15 February 2007. I hope that I will be able to finish it sooner than that.
The Red Flags book is much easier to write than HOP was. I have been writing articles on this topic for a long time, and I have been teaching classes about this for a long time, so I understand the topic very well and I already have a lot of material stockpiled.
I need more examples for the book. Please send me some! Details of what I want.
Throughout 2006 I will be visiting Perl Mongers groups to give talks about this material. If you'd like me to come visit your group, see my world tour page.
I send occasional updates and progress reports to a mailing list. The mailing list is extremely low-volume—it is not a discussion list. Typically, I send a message when I finish a chapter or when something else important happens. The mailing list gets about four messages per year.
Subscribers to the mailing list get to see draft chapters, course materials related to my books, and other goodies.
To subscribe, send mail email@example.com or submit this form:
Complete archive of this mailing list
Return to: Universe of Discourse main page | What's new page | Books by Mark Dominus | Perl Paraphernalia