But their code still works. and it works well.
Deifine "work". There's "work" as in "it runs, and covers the general case", and then there is "its robust, and will either handle edge cases without bugs, or will at least immediately stop when it detects one". A house of cards can stand a long time, as long as you don't have any sudden gusts of air or vibrations.
As for your "must-have" list:
use CGI.pm!
It's param() and header() methods are absolutely cruicial. There are so many edge cases in handling those two things that you're a fool if you try to do it on your own. You should either use CGI.pm or one of the other modules that replicate its functionality.
It's other methods (like HTML generation) are more debatable.
use strict! use warnings!
The only time I've really needed to shut off strict is the refs portion, and only for a tight lexical block. Most of the one-liners I write don't have strict, though I often end up typing my before variable names anyway, just out of habit.
I think I've only shut off warnings once, on a CGI in production that had been otherwise been working fine for months, but was spewing warnings in the error log. Again, it was only done for a single, tight lexical scope.
use placeholders!
Absolutely necessary. I have yet to see a single reason why they shouldn't be used. They are only slightly harder then interpolating the variable directly into the statement, they're infinately safer, and they're often more efficient (since the statement can be cached).
use OO!
Necessary far less then OO-purists would have you believe. OO isn't about reducing complexity, but keeping it managable. If your application is simple, then OO isn't really helping you.
It might be that a given module uses an OO-ish interface, simply because its convient to do so (though you can only call them 'OO' in the sense that they use blessed references or are called as class methods). Though I feel some modules currently using an OO-ish interface are better served with an Exporter-style (Email::Valid comes to mind).
use templates!
Should be used more often then not.
use CGI::Application!
CGI::Application is meant to be used when you have several form pages, each one feeding data from the last. I'd say if your CGI has three or fewer pages, then don't bother with CGI::Application. YMMV.
am i alone, and simply one of few lousy, undisciplined coders, or is perlmonks (as much as i love it!) a bit too perfectionistic at times??
My observation is that Perl Monks tends to be a bit different from many of the older sections of the overall Perl community. Many of Perl Monk's users (myself included) started Perl with Perl5 and a well-developed CPAN. The consequence is that many of the coding techniques used by those who have been around since Perl4 or earlier are considered bad form.
So yes, I do think Perl Monks tends further twards the more conservitive coding standards of compsci then most of the Perl community, though it is still part of the Perl community and will always be more liberal coders then Java. I see this as more of a good balance point then being 'too perfectionistic'.
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
: () { :|:& };:
Note: All code is untested, unless otherwise stated
In reply to Re: Perlmonk's "best pratices" in the real world
by hardburn
in thread Perlmonk's "best pratices" in the real world
by schweini
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |