Although most of the time I would prefer keeping my confessions private, I thought this one had to be made public for common good and enlightenment. So here it goes…
Recently I was revisiting my old code and couldn’t believe what I saw. In a few words: pure quagmire! Most of my earlier coding techniques (if one could call them such {grin}) are in direct opposition to the ones I now cherish and uphold. While writing this node Re: Oh wise Brothers where will you guide me now? up in hopes of helping an aspiring monk to set his foot straight on the path to Perl sainthood, I recalled that it was not so long ago (a mere ten months..) when I too wasn’t aware of a lot of simple truths. Some of a few things that spring to mind are ...
- Abusing global variables (that is using them a lot in many indecent ways).
- Few subs and more code dumped in the main package outside of any definite subroutine.
- Including configuration code in the same file where the main script code was kept. The beauty of this was that I would also scatter certain crucial configuration variables throughout my code in no particular order/organization.
- More obfuscation and less documentation (a breathtaking mix don’t you think?).
- No visible sign of sanity check code (using evals to catch dies/warnings, checking for boundary values etc, checking hash keys for definedness and existence to avoid vivification).
- Sloppy data structures. This included either building too complex nested combos of AoH and AoA (normally mashed together) when a simpler Hash structure would have done the job and vice versa.
Unfortunately, I still continue writing poor code to the present day, albeit to a lesser degree. I should admit however (in a futile attempt at covering up a good measure of my sins) that most of the time the driving forces behind my writing sloppy Perl code a mix of these factors:
- Tight deadlines.
There always seems to be a significant disjoint between the needs of the management and that of mere Perl practitioners (usually classified in the ‘programmers’ group). Many a times, in outlining their project schedule, managers give little regard to various software design needs and documentation. This leaves only so much time to write sloppy but (hopefully) usable code.
- Code was meant for personal use.
- Code was only a temporary solution to a problem or a patch.
- I was too lazy to think any better.
And what are (were) your reasons for writing sloppy Perl code?
_____________________
$"=q;grep;;$,=q"grep";for(`find . -name ".saves*~"`){s;$/;;;/(.*-(\d+)
+-.*)$/;$_=["ps -e -o pid | "," $2 | "," -v "," "]`@$_`?{print"
++ $1"}:{print"- $1"}&&`rm $1`;print"\n";}
-
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.
|
