On Thursday, April 18, 2002, at 05:35 , Anthony Beaman wrote:
[..]
> I then try to study code but it's usually beyond me.
[..]
always remember
perldoc -m <MODULE>
will let you skim through the module completely - POD/Code/Comments.
the three responses I have seen from Felix, Jonathan and Jenda
each covers their strengths in their area -
So the simpler rules are:
1) play with the beginner's list questions
any solution posited - should be challenged by you
in the privacy of your own code space - if it 'works'
know WHY it works. eg:
so WriterFoo posited X - what if I do Y to it....
if You Can't Blow It Up - you are just not trying.
2) look at the questions being raised here
see how you would solve that problem - and why, as well as
which specific
clues in the perldoc are
more relevant to your solution.
3) become a friend of 'use Benchmark;' - so that you
do not fall prey to the 'popular myths' - establish the
standard that you will use for your own analysis.
BENCHMARK IT! PROVE IT! IF there Ain't Smoke, you
clearly could lean on it harder...
4) have a 'coding buddy' - someone who will be willing to do
code reviews with you - and run the 'idiot drills' - if you
can not explain what it does - in the comments/POD - then
rework it. { did I mention - Benchmark it for you to verify
that the 'make test' part works as advertised???? }
TRUST NO ONE! Trust ONLY the Code that you have validated yourself.
Now, assuming that you are interested in this as a profession,
try to establish your own professional standards. Most PerlMongers
do this because of our unresolved childhood issues and other forms
of obsessive compulsive disorders. We are beyond repair or rescue.
You may be able to learn from our mutant mistakes.
Hence
a) get a life - understand the difference between you
and the code that you hack. Be ready to kill off any
code that you have hacked if you find a better way. It
is not You, You are Not Your Code.
b) don't code till Oh Dark Squat - remember your higher
order analytics fail first - hence if you think that
<X> is a bright idea - it will still be a bright idea
in the light of day - IF it is a bright idea. If as many
of us have learned the hard way - it looks like the stack
of old pizza boxes, munchies, and other bio-hazards in
your coding place - RUN AWAY FROM IT!
c) learn to forget. Merely because you have figured out
as I did yesterday - the difference between my, our, local -
if this does not change your core rules on how you manage
memory allocation by variables - note why the tricks work
and then forget them, and stick to your guns.
d) write some "cute" code - forget to document it - and come
back in a year or two and try to figure out what in god's
green earth it does and/or why ever did you write it.
this will teach you to eschew all 'cute code' that you do
not document appropriately - since it is better that you
plan to have this experience, than that your production code
comes back to BITE YOU.
e) eat real food regularly.
f) exercise daily
g) change your socks and underwear.....
h) My God Man get that BioHazard out of your Coding Place....
any questions?
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
