I would summarize my feelings on the matter thusly:
-
No matter what else you do, be crystal-clear.
Also avail yourself of everything that Perl can do for you through the use of:
use strict;
use warnings;
-
Remember that the mod_perl (and FastCGI) environment is persistent. The program may remain in memory for some time, and this can create severe debugging issues unless you make it a point to ensure that every single thing has a known value (or is known to have no value) at all times.
-
Perl has many debugging tools, analyzers, and regression-testing tools.
You see them used in major CPAN modules all the time.
There are many benefits indeed to be gained from the practice of building your own modules to an equal degree of rigor.
Many of the CPAN modules we use today evolved from this practice.
One of the nice things about the Perl world is that “best practices” about a great many things are both carefully spelled-out, and carefully explained.
In the true spirit of TMTOWTDI, you don’t have to follow them. But it is invariably wise to do so.
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|
