You're looking for CPAN

Happily, however, the journey is ongoing. As you come to understand more of what you encounter the urge to read code will become stronger and you'll find yourself skipping to the source before you read the documentation.

Note that it can be just as useful to read bad code as it is to read good, what's important is to keep interested in self-improvement.

There are loads of examples of funky Perl code out there but if you're looking for real-world good stuff, here are a couple of favourites:

• When I browse the source for Template Toolkit I am always in awe, thinking “man, that is so much more organised than my code!”.
• Newcomer CGI::Prototype is almost enough to make me give up coding altogether in how infuriatingly sensible it is (instead, I decided to use it as the basis for my latest project).

And look at the whizz-kids here. Perlmonks isn't like other forums¹, there are regular contributions from some of the best minds in the business that frequently question how [id://matthewb|this] little contractor writes his code.

[1]. Kidding about that link ;)

Newcomer CGI::Prototype is almost enough to make me give up coding altogether in how infuriatingly sensible it is

{blush}

I suppose the real thing that drives my coding for stuff like that is the sensible "Smalltalk Best Practice Patterns" by Kent Beck, an excellent book for basic object oriented programming, even though it is focused on Smalltalk. (And supports my idea that you really can't say you "do OO" until you've practiced in Smalltalk at least for a short while.)

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

The Perl Cookbook is filled with many snippets and short programs written in exemplary Perl.

As for the links to a "good" code, I would advise to look in the Code Catacombs - the approved code from the hardworking monks :)

I actually find that PM has a lot of excellent code. Just look in just about any section.

After about spending a month or two on here, you will see a lot of great code, but just not from me ;-)

Something to strive for.

But do take a deep breath first and a deep breath after.

...

And possibly a deep breath instead of.

Writing obfuscated code is fun, and certainly a challenge, but it's really a very specialized niche. Learning how to do it may teach you a lot of Perl features, but it really doesn't teach you how to use them well. I think the latter is more important than the former, and hopefully you'll agree that obfuscation is not the best example of it.

I agree, the camel is not a practical example of nice structured code. But it still is an amazing thing of beauty, which was my point. And if you can do that, you know you can probably do the day-to-day stuff well.


—Brad
"The important work of moving the world forward does not wait to be done by perfect men." George Eliot

As far as standard formatting goes, always write your programs for use strict and use warnings; define all variables at the top of the section that uses them; insert comments wherever you're likely to have problems remembering the mechanics of your code later. Use some sort of standard naming scheme for variables and subs that avoids case sensitivity problems and name collisions.

Read through the posts here every day and try to solve the algorithmic problems on your own. Then compare to posted code. My code formatting got worlds better within a week or two of doing this.