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";}
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.