Pod::Usage is great in conjunction with Getopt::Long. I'm not sure Getopt::Declare does both jobs.

Most of the POD-related modules are great, in fact — assuming you are properly diligent to create POD for the code you write.

CGI::Application makes CGI scripts that much clearer.

So does the Template Toolkit.

Class::DBI makes database use trivial.

The last three modules and misc utility modules available for them have enabled me to write a web database application with almost no code at all (inspired by Kake Pugh).

CGI::Untaint and Data::FormValidator make the tedious job of validating input much easier.

Imager is great for any kind of 2D graphics, particularly graphs (it will scale them and add grid and axes automatically). I've found it much nicer than GD and friends.

I think that most pretty/well-dressed code has a few common characteristics. Many of these characteristics overlap, which is a good sign that they will probably be describing the same thing.

• It's well-factored
• It's easier to read than other implementations
• Variables are well-named
• There's a minimum of abstract units
• Those abstract units are well-documented
• Any deviation from these characteristics is well documented and explained

Basically, if I have to wonder what you did and/or why you did it, that's a problem. If I have to parse through $aa, $aaa, and $aaaa (which is actually in some code I haven't been given permission to rewrite yet) ... that's a bigger problem.

Prettiness is predicated upon usability.

I've always enjoyed reading the various Paul Graham articles pointed at by monks, and this one is no exception.

I disagree with one part of it though:

Not every kind of hard is good. There is good pain and bad pain. You want the kind of pain you get from going running, not the kind you get from stepping on a nail. A difficult problem could be good for a designer, but a fickle client or unreliable materials would not be.

While I understand his point, I think it all comes down to how you react to these minor torments. If stepping on a nail just causes you to jump around going 'ow' a lot, no great gain. If it causes you to design a new nail, or a new shoe, that'd be quite another matter.

Similarly, a fickle client gains you nothing if you just throw away and rewrite (or start to pile hack upon hack); however if it causes you to redesign your application to make it easier to respond to changing requirements that'd be a good thing.

In software, I find that simplicity and elegance often reflect good prediction - you've correctly guessed what types of flexibility will be called for in the future, and provided for them, so that the software has not degenerated into a mess of hacks as requirements have changed (as they always do).

Hugo

I agree with your sentiment, but it doesn't play out in the real world the way you hope. An analogy would be that a client goes to the best sprinter in the world and says "I need you to run the 100m race tomorrow." Not a problem, right? Well, that night, the client calls the sprinter and starts to describe the outfit. Ok, still not a problem. The chicken outfit isn't aerodynamic, but he can still run the 100m race. Then, that morning, the client says "I need you to run it in world-record time."

A real world analogy is what's going on at work right now. The main application is suffering from a very poor design, continuously shifting requirements, and lots of developer turnover. This has caused it to place inordinate load upon the database server. We hadn't been able to upgrade it because the parts were unavailable. (Yes, that does happen, even to Sun servers!) So, performance degraded exponentially with the number of new users, and we've been adding 20 employees a month. So, what worked for 100 employees doesn't when you have 200+.

The VP says "I need the performance improved." We tell him your choices are:

1. Buy more servers
2. Rewrite the app so that it doesn't place that inordinate load

His response was "I don't like those choices. Give me another one."¹ Or, how about the time we moved into a second location and had problems with the bandwidth between the buildings. That was impacting the users. So, he calls us into his office and says "What can we do to solve this, but don't suggest adding bandwidth or any new development."

It's nice when you can predict the future "needs" of your clients, but if you can do that on a regular basis, you're either in the wrong business or you ended up with a bloated mess called Windows.

1. We wanted to say something along the lines of "Sure. Give me a second to reach up my ass for that!", but then we wouldn't be able to pay our mortgages. :-)

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

What makes it pretty? In my opinion, it's about maintainability. For me, a well-formatted comment block at the beginning, chock full of info; inline descriptive comments; well-chosen variable names; and some good man page POD added after the __END__ make for what I think is "pretty".

Even if the algorithm is inefficient, the copious documentation and notes should allow for someone to "upgrade" it in the future. Admittedly, using a well-defined interface would help allow user-transparent upgrades.

One disagreement.

Copious documentation in my experience tends to become bad documentation. Documenting everything leads to unmaintained comments that, over time, wise maintainers learn to ignore. Documentation needs to have a clear purpose, accomplish that purpose, and not attempt to do more.

As I0 said a long time ago, I find the most useful comments state what remains invariant, while the code states what gets transformed.

A past thread on this is Re (tilly) 2 (disagree): Another commenting question,. A couple posts into that thread you'll find a set of coding guidelines for when I do (and don't) comment, and why. I still pretty much follow that.

The suit is the uniform of the devil's army. ;-)

The suit is the uniform of the devil's army. ;-)

No, that would be New York Yankees uniform.

--
tbone1, YAPS (Yet Another Perl Schlub)
And remember, if he succeeds, so what.
- Chick McGee

water here again. Your quote from your teacher, scarborough, really summed up what I was trying to say, much more succinctly. ++