Slashdot Mirror
Perl Best Practices
honestpuck (Tony Williams) writes "I have to admit that I can bristle at books that try to preach, so Perl Best Practices was on a hiding to nothing when I came to review it. I also have to admit to being torn about the author -- after all, he is one of those poor fools who insist on living in cold, unenlightened Melbourne, while I live in vastly superior Sydney. On the other hand, how can I dislike a man who manages to place a quote that involves my favourite character, Lady Bracknell. from my favourite comic play, 'The Importance of Being Earnest,' in the first few pages of his book?" Read on for Williams' review.
Perl Best Practices
author
Damian Conway
pages
492
publisher
O'Reilly Media
rating
8
reviewer
Tony Williams
ISBN
0596001738
summary
Methods of coding to improve your Perl software
Many years ago I read a marvelous article that explained why so may early editors and word processors supported the keyboard commands of WordStar. When it's first born, a baby duck can be easily convinced that almost anything is its mother. The small bird imprints, and it takes a lot to shift its focus. "Baby Duck Syndrome" affects programmers in a number of ways, not just their choice of editor, and Conway is walking right into the middle and arguing with your imprinting on almost every page. A brave man; fortunately he has the street cred to make you at least listen.
So I carefully placed my bias and bigotry in the bottom drawer and prepared myself. I discovered a well-written, informed and engaging book that covers a number of methods (hey, 256 rules, come on Derrick, 2 ^ 8 rules can't be a coincidence!) for improving your Perl software when working in a team. That means all of us when you remember an adage a guru once told me: "Every piece of computer software, no matter how small, involves at least a team of two -- me, and me six months from now when I have to fix it." Conway puts it differently "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
The first chapter outlines the why and where of the book. The why is to improve your code with three goals; robustness, efficiency and maintainability. The chapter finishes with a short exhortation to us to "rehabit." Don't like the word much but I applaud the aim.
Conway is far from timid. He jumps right in to the deep end of the wars, with formatting the appearance of your code. I thought the chapter was brilliantly written until he told me I shouldn't "cuddle else statements," at which point I realized what an ill-informed idiot he was. Oh, hang on. Hey, that almost makes sense. OK, that's a cogent argument for your point of view, Conway. I also have to admit that earlier you did say that your rules for this bit weren't gospel, that if you wanted a variation that was OK, just have a standard and make sure you can support it with a code prettier. Perhaps not a total idiot after all.
After successfully negotiating those shark infested waters, Conway -- obviously a man who knows no fear -- wades into naming conventions. Once again he gives coherent arguments, pointed examples and counterexamples. It all makes sense.
The book's page at O'Reilly has an example chapter and a good description, but no table of contents so here's a quick list of the headings:
The book is also well-written and well-edited. The order of topics covered is a sensible one, and the book is appropriately structured. It reads and feels as if you are being given the wisdom from many a hard-won battle coding and maintaining Perl code.
My one complaint is that I found it dry: you are reading through pages of argument and examples without much relief. Perhaps this book might be best digested in a number of chunks, making the effort to use the ideas from each chunk for a while before moving on to the next.
Every so often I read a book from O'Reilly that makes me fear that they are slipping, then along comes a book like Perl Best Practices, and I'm reminded that when it comes to Perl, O'Reilly authors wrote the book. Once you've rushed through Larry's book and learnt the finer points with Schwartz and Phoenix's 'Learning' titles, you may well find that this is the perfect volume to complete your Perl education. If you believe your Perl education is complete, then buy this volume and I'm sure you'll find a lesson or two for yourself.
This book is not really aimed at the occasional Perl programmer (though many of us would probably benefit from its wisdom), but at the person who is professionally programming in Perl and wants to produce better quality, more easily maintained code. For this person Perl Best Practices is a 9/10. For the rest of us, the 'rehabiting' process might be a little too arduous; personally, I'm going to pick a few of the chapters and work on those for a while, maybe naming conventions and variables. For me I'll give it an 8.
You can purchase Perl Best Practices from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Many years ago I read a marvelous article that explained why so may early editors and word processors supported the keyboard commands of WordStar. When it's first born, a baby duck can be easily convinced that almost anything is its mother. The small bird imprints, and it takes a lot to shift its focus. "Baby Duck Syndrome" affects programmers in a number of ways, not just their choice of editor, and Conway is walking right into the middle and arguing with your imprinting on almost every page. A brave man; fortunately he has the street cred to make you at least listen.
So I carefully placed my bias and bigotry in the bottom drawer and prepared myself. I discovered a well-written, informed and engaging book that covers a number of methods (hey, 256 rules, come on Derrick, 2 ^ 8 rules can't be a coincidence!) for improving your Perl software when working in a team. That means all of us when you remember an adage a guru once told me: "Every piece of computer software, no matter how small, involves at least a team of two -- me, and me six months from now when I have to fix it." Conway puts it differently "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
The first chapter outlines the why and where of the book. The why is to improve your code with three goals; robustness, efficiency and maintainability. The chapter finishes with a short exhortation to us to "rehabit." Don't like the word much but I applaud the aim.
Conway is far from timid. He jumps right in to the deep end of the wars, with formatting the appearance of your code. I thought the chapter was brilliantly written until he told me I shouldn't "cuddle else statements," at which point I realized what an ill-informed idiot he was. Oh, hang on. Hey, that almost makes sense. OK, that's a cogent argument for your point of view, Conway. I also have to admit that earlier you did say that your rules for this bit weren't gospel, that if you wanted a variation that was OK, just have a standard and make sure you can support it with a code prettier. Perhaps not a total idiot after all.
After successfully negotiating those shark infested waters, Conway -- obviously a man who knows no fear -- wades into naming conventions. Once again he gives coherent arguments, pointed examples and counterexamples. It all makes sense.
The book's page at O'Reilly has an example chapter and a good description, but no table of contents so here's a quick list of the headings:
- Best Practices
- Code Layout
- Naming Conventions
- Values and Expressions
- Variables
- Control Structures
- Documentation
- Built-in Functions
- Subroutines
- I/O
- References
- Regular Expressions
- Error Handling
- Command-Line Processing
- Objects
- Class Hierarchies
- Modules
- Testing and Debugging
- Miscellanea
The book is also well-written and well-edited. The order of topics covered is a sensible one, and the book is appropriately structured. It reads and feels as if you are being given the wisdom from many a hard-won battle coding and maintaining Perl code.
My one complaint is that I found it dry: you are reading through pages of argument and examples without much relief. Perhaps this book might be best digested in a number of chunks, making the effort to use the ideas from each chunk for a while before moving on to the next.
Every so often I read a book from O'Reilly that makes me fear that they are slipping, then along comes a book like Perl Best Practices, and I'm reminded that when it comes to Perl, O'Reilly authors wrote the book. Once you've rushed through Larry's book and learnt the finer points with Schwartz and Phoenix's 'Learning' titles, you may well find that this is the perfect volume to complete your Perl education. If you believe your Perl education is complete, then buy this volume and I'm sure you'll find a lesson or two for yourself.
This book is not really aimed at the occasional Perl programmer (though many of us would probably benefit from its wisdom), but at the person who is professionally programming in Perl and wants to produce better quality, more easily maintained code. For this person Perl Best Practices is a 9/10. For the rest of us, the 'rehabiting' process might be a little too arduous; personally, I'm going to pick a few of the chapters and work on those for a while, maybe naming conventions and variables. For me I'll give it an 8.
You can purchase Perl Best Practices from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
If it looks like an emoticon, your Perl is probably syntactically correct. ;)
Skype is too convoluted... Now I'm reverse-engineering the Kyoto Protocol.
Perl programmers always say they can do anything in one line of code. Does this book finally set a limit on how many characters can be in that one line?
Perl Best Practices, page 1.
Use Python.
Ba-dump-bump! Thanks, I'll be here all week. Be sure to tip your waitresses.
Weaselmancer
rediculous.
Do you know why Apple pioneered Command (nee control) Z, X, C, and V for Undo, Cut, Copy, and Paste? Take a look at a QWERTY keyboard: they're the easiest keys to hit with only the left hand. Same for Command-W for close, Q for Quit, and A for select all: one handed operation, leaving the right hand free to drive the mouse.
I grant you, left-handers and non-QWERTY keyboarders are left out in the cold, but at least there was a method to the madness.
Ofcourse if you're using Perl4 and below, you're out of luck...
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
What's the point of using Perl if your code suddenly becomes intelligible? After all, there is more than one way to obfuscate it.
In Soviet Russia, Jesus asks: "What Would You Do?"
after all, he is one of those poor fools who insist on living in cold, unenlightened Melbourne, while I live in vastly superior Sydney. On the other hand, how can I dislike a man who manages to place a quote that involves my favourite character, Lady Bracknell. from my favourite comic play, 'The Importance of Being Earnest,' in the first few pages of his book?"
Oh, you do slay me, mate.
Is this like http://slashdot.co.au/ or something?
Your hybrid is not saving the environment. Its purpose is to make you feel good about buying something.
My Data Structures professor once said: "Perl is a write-only language" :)
All your Sybase are belong to us.
O.K. so you are not using new lines and threw in a regular expression to make things look difficult. What is your point? I can gen up an equally obtuse statement in C and C++.
(BE) ON A HIDING TO NOTHING -- "Face annililation. Or, less dramatically, 'face insuperable odds,' 'be without a prayer,' i.e., with no hope of success. 'Hiding,' in this expression, is synonymous with 'thrashing,' and a 'hiding to nothing' means 'a thrashing to bits.'" From "British English: A to Zed" by Norman W. Schur (Harper Perennial, New York, 1987).
there is one rule of coding style: you should have one.
In a similar vein there was a recent article by the same author printed on perl.com:
I picked up this book probably a month ago, and for a seasoned perl dev who plans on exposing his code to the world, it's definately worth picking up.
One nice feature I found was the chapter on formatting included vim and emacs config snippets to achieve the same effect, as well as the config file to use perltidy to do the same thing.
I agree it is dry, and it's very "bam bam bam" with the examples. Not something you can read start to finish. you'll want to try implementing things right away. I suggest taking the book a chapter at a time and implementing the changes in your code then.
There were some bits I agreed with, and some I didn't agree with; however the parts that I didn't agree with they explained in a reasoned and rational manner, and made me rethink my own thoughts on the subject.
I've recently fallen into the position where I'll be leading possibly two other developers- this book will become a standardization format for our company.
again, I highly recommend this book.
-morgajel
Looking for Book Reviews? Check out Literary Escapism.
Jeezis, what a lame review. Three paragraphs about the reviewer, then a listing of the table of contents, then a few useless comments like "it's edited well", "it's dry". The author doesn't like uncuddled elses, and takes issue with "rehabit". Waa! How about mentioning some of the actual best practices?
That a joke? I don't think there's any language that can be fully understood after a 2-semester course.
Sometimes you NEED glorified shell scripts, cause otherwise the shell becomes bloated with features that most people don't need.
excitingthingstodo.blogspot.com
Amazing how the importance of typing one-handed has never evaded software engineers.
Perl didn't decrease in popularity, the others increased as people found out they can do "professional" websites in php, etc.
RoR would be nice but it lacks the granularity of perl.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Being a Python programmer, not a Perl programmer, I'm sure you won't be angry if I point out your syntax problem: you forgot the semi-colon. It's a common mistake though. The proper syntax is:
use Python;
Actually, there are 4 (5 if you count the empty regex after the first split):
//
/ ^$P/ix
/^[ P.]/
/^r/
/\S/
I agree with the grandparent, I don't get how this code example means Perl is bad. You can do something similar with any language that doesn't require newlines between statements, and which allows regular expressions.
Ironically, the word ironically is often used incorrectly.
As a perl programmer, I can assure you that:
1) There are reasons to use Perl. Nothing REQUIRING it, granted, but that's true of any language. Python and Ruby inhabit similar but not identical niches.
2) Line noise reputation aside, Perl can be _very_ readable. Concise done correctly means that it says what it does and does it, without unnecessary compiler syntax effort. Concise done wrong means it's not obvious what you are doing. Perl gives you enough rope to hang yourself...kind of like computers, and open source in general.
3) As far as the book goes, I was eager to get my hands on it and learn, but worried that I'd find it too limiting and restrictive. The tips ranged from the obvious (strict and warnings), the non-syntactical useful (use code and documentation template for new projects), to the small but fascinating (make your hash names end it words like "for" or "of", so that normal usage is self documenting: $name_of{$user} ). Very few of the tips did I disagree with, and even though the book talks about the importance of HAVING standard practices over what those practices are, I'm moving my dept to adopting the standards in the book because my preference is often habit over any calculated reason.
Perhaps 50% of the tips have nothing or little to do with Perl and everything to do with programming, programmers, or users.
This is not a life altering book. It is, however, a high quality book with some very good tips.
I, too, purchased the book about a month ago. I was hoping it would be sort of an "Effective C++" but for Perl.
It's nice to have, and it gives me things to think about for improving code, but it's by no means essential.
In some cases, the author's advice is inconsistent. For example, he sometimes suggests that a programmer avoid constructs that would force a reader to look something up. And some other times, he suggests using a construct (e.g., \A and \z instead of $ and ^, respectively, in regular expressions) BECAUSE it's unusual and many people will have to look it up.
--I'm so big, my sig has its own sig.
-- See?
"Cuddling" else means doing this:
instead of this:
--Phillip
Can you say BIRTH TAX
Sure there is. Brainf**k, for example, which has only eight instruction types. Or Malbolge, where you can peruse all existing programs in an afternoon.
Cuddled:
} else {
Uncuddled:
}
else {
or
}
else
}
(Suitably indented of course.)
'Sensible' is a curse word.
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLOWORLD.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500 DISPLAY "Hello world!" LINE 15 POSITION 10.
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.
...and the poor guy didn't get a cent from that - so go out and buy this for all your devs, and buy Peopleware by Tom Demarco for all your managers while you're at it.
;-)
I get a copy for every new dev now. I'm not going to force them to use all of it, but it definitely makes them think when they start working on larger projects.
I'd also recommend MJD's Higher Order Perl if you want to go even deeper.
I always think it's funny when people argue heavily about hating to work to a "best practices" style. And then start agruments about how crap Perl is because it's unreadable. Anyway - I digress.
cLive
-- Trinity in high heels carrying a whip: The donimatrix - there is no spoonerism
Why is this marked as offtopic?
Both comments are clearly ontopic flamebait.
For readers outside of Australia - Melbourne and Sydney have a rivalry big enough to affected the placement of the capital (Canberra) - it was eventually placed halfway between Sydney and Melbourne.
Even the Australian Constitution had a clause that Canberra must be more then 100 miles from Sydney.
I like honestpuck - but that statement is a troll. Not a particularly funny one unfortunately - because not enough people will get the joke.
My pics.
Which, IMHO, is the best thing to happen to Perl. One of the main reasons why Perl got such a bad reputation is because it is very easy to pick up. The web was (and still is) littered with a huge amount of Perl snippets written by teenage script kiddies who think that Perl and CGI are synonyms (Matt's Script Archive comes to mind).
Personally, I have been using Perl professionally on an almost daily basis (and I'm NOT in IT or software) for over 7 years now, and have never written a single CGI program.
Just because you don't see any web scripts written in Perl doesn't mean Perl is finished. I would actually consider that a new beginning.
It's also not worth our time rewriting it.
Not too long ago, I discovered the results of operations testing on various languages. Python was the worst in every category except one, where Java (1.4.x) became the worst (Java 1.4.x was the second worst in most of the other cases). This benchmarking, however, was a couple of years old, so it's possible other improvements have been made along the way.
For doing various system administration tasks, file massaging/processing, and stuff like that, I find perl to be quick and easy to use. Mainly because perl's regex engine has been so highly optimized, it tends to run a lot faster. I also have general issues with languages that are white-space dependant for their syntax... which is why unless it's something really simple, I tend to avoid UNIX shell scripts too.
I've also had a Java addict compliment me on my perl style, syntax, etc, because it was clear and readable... and this was for a major financial securities project.
If you really want a "best practice," try writing clear, understandable code, regardless of the language you use. It'll get you further.
OCO is Loco
Is Amazon big-name enough for you?
http://www.masonhq.com/?AmazonDotCom
(Mason, btw, is a templating system written in Perl)
More to the point, you will write crap in any language if you don't understand the conventions, idioms, and best practices of the language.
Perl is a lot like Lisp. You need to think in terms of lists before you see anything but the sigils and you tend to write "C in Perl". Further, until you see *good* Perl code, it's hard to know any better. Before this book, the book I'd refer people to was "Effective Perl Programming" by Hall & Schwartz. The goal was to get beyond "baby talk" and use the language well.
I'm about 130 pages into "Best Practices" and I like the book a lot. It's definately on the required reading list for any Perl programmers that we hire.
I can't say I agree with Damian about *all* the conventions (I really *like* "unless") but I agree with most of them, and having met him once, I'll admit that he knows more about Perl than I'm ever going to know, and more about computing languages and PROGRAMMING best practices than most of the people that have responded to this topic.
If you code in Perl often enough that you wish your code was better, you should pick up this book.
In 5 years of studying computer science (BS, MS) I was never formally taught Perl in a class. I learned it as the side effect of a Relational Database class. Now, 6 years later, I use Perl, ASP, and Microsoft Access on a daily basis. Not exactly the path I envisioned when I was a bright eyed 21 year old open source zealot.
/(.*?)the/; /(.*)the/;
Anyway, last week my mom told me it was important for me to start giving back to society, so here is your Perl tip of the day. It took me a few months of writing awful, inefficient regular expressions to learn this doozy:
the ? is your friend. It forces regular expressions to search for the first match, instead of the last."
Example:
$test = "Perl regular expression tip of the day: the ? is your friend. It forces regular expressions to search for the first match, instead of the last.";
$test =~
print $1;
print "\n--\n";
$test =~
print $1;
C:\>perl test.pl
Perl regular expression tip of
--
Perl regular expression tip of the day: the ? is your friend. It forces regular expressions to search for the first match, instead of
Comment removed based on user account deletion
... yours truly, slashdot? Yes, perl. And Amazon.com, perl too. Show me PHP websites of this magnitude...
and Haskell is being used to _implement_ the Perl 6 compiler for the same reason Python or Ruby interpreters are writter in C. Except, of course, Haskell is a lot higher level than C and more secure, meaning the current size of the project is just short of 4K lines. and no side-effects... ^_^
I don't feel like it...
Perl is getting to the point where you need a 2-semester college course on the subject before you can fully understand all aspects of the language.
Perl's syntax is very complex; it has a lot of operators and provides many different ways to do the same thing. This makes reading other people's code very difficult.
Everyone starts by learning a subset of the language, then building upon that by learning more after they've mastered the basics. You can write a lot of perl code without knowing half the syntax. The problem is, since everyone learns a different subset, reading someone else's code is impossible for a beginner, and unfamiliar syntax isn't something you can easily look up in a reference. A language like PHP has a simpler syntax and far fewer operators, and makes up for it by having a large number of functions; once you've got the syntax down, you can just look up unfamiliar functions in the documentation and figure out what's going on. The result of this is that PHP looks easier to beginners while Perl looks daunting.
I'm completely ignoring Perl 6, and I'd advise others to do the same for at least a few more years.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
I don't think there's any language that can be fully understood after a 2-semester course.
I disagree. Most people I know are able to completely master pig latin with just a couple of days of study and use.
CPAN? Though let me know if it's not exactly what you had in mind.
One of the reasons we're able to write quick throw-away scripts for virtually all purposes in Perl is that we have a massive Perl codebase to draw from. CPAN is often cited as one of Perl's greatest strengths, particularly against the likes of Ruby, Python, and even PHP. Not that their communities aren't moving in this direction, but the fact that each has projects whose mission statement is essentially "Be like CPAN for [insert language here]" should be an indicator of what remains desirable with Perl, and how we might characterize it as a big-name project.
And if there's one place where you'd want to maintain best practices...
Linux is not Windows
1. Don't
while (!asleep()) sheep++
The problem with the program in question where I work is that it was poorly designed from the get-go. I can tell you for a fact that the vast majority of the program's run-time is in the single line that prints out a 512MB object to a file in human-readable format.
Languages are tools. You should use the tool that's best for the job, not because it matches the newest buzz-words.
OCO is Loco
They have languages for that?! Oh man am I clueless.
amazon.com
:)
ticketmaster.com
imdb.com
slashdot.org
Just a few of the sites that run Perl...
Pugs is more of a tool to aid in development of Perl 6, it is not the official "to be released" Perl 6.
Personally I find Perl to be very useful in large scale enterprise development. You can write bad code in any language ( yes any language ), that is the fault of the programmer not the language.
It's like trying to blame a poorly constructed house on the fact your dremel tool has 9,000 options to it!
I had a theory about this, so I checked it out with this frequency table and Gnumeric.
In the Qwerty layout, more of the most commonly-used letters are located under the left hand. Taking the limit as T, G, B, you can hit about 57% of letters by frequency. If you include occasional jumps as far as U, J, N (within reach of my relatively small hand), it's nearly 73%. Thus, it's more useful to keep the left hand on the keyboard. You can of course argue that one could move the right hand across, but the left hand starts from an advantageous position for one-handed typing.
If your comment title says 'Re: Foo', I'm not likely to read it.
Indeed, it does.
;-)
Right at the start on page 18:
Use 78-column lines.
Bet you didn't expect that
In other words, if all you know is the syntax, you don't know the language.
erm ... using python might be really better in some cases, but you should be reminded that almost every unix box has perl and as maybe a shocking surprise to you, pretty many of them are missing python ... for example a minimal debian install has perl but lacks python. i put up most server like machines with pure debian at start, so i have no python until i fetch a program that needs it.
... this makes large python applications pretty manageable and turns large perl applications often into a mess. althrough the problem with both languages for me is that 3-rd party site packages likes wxwindows/tk/opengl bridge packages are often in broken dependancies and it really can make you swear a lot if you want to upgrade your box and because of 1 dependancy half of the python/perl gui programs wave you bye-bye. cant they really integrate some form of gui that would be python/perl native and work across platforms ? this way i would depend on 'john smith' to get some nice python/perl widget running ...
:(
:) (idea is good but current implementation does really cut it yet)
imho the power of python isnt the clear syntax, clear syntax can be written in perl too, some people are just too lazy to do it. python has really good threading and a nice oop model, perl's ithreads are still quite a mess and the variable & oop layer across it is even fuzzier and more difficult to bite through than the h4x0r'5 scripts
both languages are excellent for writing tiny helper tools for linux (tools that linux is missing a lot for dumb users), C and Java are both overkills for such simple tasks (a nice example of an overkill is a installer that is powered by a java gui, this is inhuman, uses twice the memory and need a bloating jvm to run). but without a really stable and "always being there" gui package these tools break a lot
i believe that perl is good in it's own key places, mostly being compact and very portable. in large and multithreaded applications ofcourse python rolls the house in the scripting world.
and for ruby fans, lets wait until the next version rolls out, then we may have a really good spot for that one too
use the right tool for the job and for the best practices use strict and warnings in perl, indent your code and avoid regexp hacks where you dont need them.
I'd tell you the chances of this story being a dupe, but you wouldn't like it.
Everyone starts by learning a subset of the language
As someone who regularly downloads and fixes broken perl modules, I have to disagree.
Everyone tends to use the same subset at the start.
The big thing you see in a beginner's code are just control structures (especially foreach statements), and regular expressions (and then mostly only stuff you'll see in an awk expression).
Things like inventing a new inheritance structure (as is done by Class::DBI, OOTools, and PDF::Template), embedding a LALR parser (all the template engines), are a sign of a mature coder, and happen much less. These people are more likely to write code in a logically consistent, well designed manner such that it is easy to extend.
So far I've found one module that I tried to fix (and ended up not because it was too much work) that wasn't either simple or well designed (Class::DBI::FormBuilder).
Mod me down and I will become more powerful than you can possibly imagine!