3.5 Developing
There's no substitute for knowledge. Coding something you don't understand should set off warning bells in your brain: "What does the code I just wrote really do?" That's the time to experiment.
I have seen too many people take a shotgun approach to coding: they just fire a blast of characters onto the screen and rearrange them until something works. Too often, instructors foster the mindset that the only thing that counts is getting the right answer: I keep finding people who put something in a program "because it works"—in that particular situation—but don't understand what they are doing and so can't extend it to other situations or aren't aware of how it might fail.
Nevertheless, there are times when you have to do something quite beyond your current ability or the rate at which you can learn something new. Here are some useful ways to cheat:
-
Steal. Tom Christiansen and Nathan Torkington have gone and left a pile of code in a fat book5 at your local bookstore which you can use for anything you want and they'll never complain. If you find the task you're trying to solve in there, have at it. You can always break your overall task into smaller logical units that are more generic and therefore more likely to be in the book.
Mutate. Start by using good code that does something similar to what you want, and gradually change it to fit your needs. Even though there may be code you don't understand in there, it may stay isolated from your changes, so you don't have to worry about it. (Anyone who has subclassed a module is familiar with 2. this way of thinking.) How do you recognize good code? Emulate the best.
Now, whenever we've asked who to emulate, people have been reluctant to name anyone in particular. We applaud their sense of fairness but the result is frustrating. Therefore we present our totally biased, incomplete, but still useful list of authors whose code you can find on the net, the copying of which will likely lead to good results.6 We've put the names in alphabetical order to avoid any more outrage than necessary.
|
Gisle Aas |
Uri Guttman |
Chip Salzenberg |
|
Greg Bacon |
Joseph N. Hall |
Gurusamy Sarathy |
|
Graham Barr |
Jarkko Hietaniemi |
Randal Schwartz |
|
Tim Bunce |
Nick Ing-Simmons |
Michael G. Schwern |
|
Alan Burlison |
Ronald Kimball |
Lincoln Stein |
|
Nigel Chapman |
John Macdonald |
Mike Stok |
|
Tom Christiansen |
Tad McCl el l an |
Nathan Torkington |
|
Damian Conway |
Chris Nandor |
Hugo van der Sanden |
|
Simon Cozens |
Jon Orwant |
Johan Vromans |
|
Mark-Jason Dominus |
Tom Phoenix |
Larry Wall |
|
Jan Dubois |
John Porter |
Ilya Zakharevich |
|
brian d foy |
Larry Rosler |
|
Note to the obviousness-challenged: this wasn't a popularity contest and we're not handing out awards. Of course there are dozens of other people we could have added, and hundreds more are worthy of inclusion in such a list if only we were aware of them all. (And if you're in that category, we apologize to you.) We print it here because it's the kind of list we wanted, and couldn't find, when we were beginning Perl. Arbitrary and incomplete as it is, we believe it to be superior to no list at all.
Now, when you're mutating code, be sure and test that the original works before you change it!7 This admonition has nothing to do with the reliability of its author, rather the fact that everyone's environment is different, and maybe the difference between yours and the author's is significant. (Sometimes we have spent ages trying to find bugs in changes we made while mutating code only to find that the problem was in the original.)
Then modify as little at a time as possible to get something you can test. Change the parts you understand the best first—like the names of input/output files and e-mail logging addresses—test, and keep going with the harder parts. With luck, you'll eventually end up with what you need without having to touch the parts you don't understand. (Anyone who's subclassed a module and had to override the constructor and other methods is familiar with this approach.)