Your skill will accomplish
what the force of many cannot
Learning perlisms leads to experience, wisdom and discoveries that whitespace & idioms are lazyby Mr. Muskrat (Canon)
|on Dec 23, 2004 at 07:08 UTC||Need Help??|
I have been working as a programmer (among other things) for the past several years. In this time, I have picked up some knowledge that I would like to pass along in the hope that you will not make the same mistakes that I and those around me have already made.
Notice that I did not say those who are older than you, have more seniority or hold a supervisory position over you. In some cultures this is a hard concept to grasp. Give that "kid" a chance, she might teach you a thing or two about proper programming.
As for the "lack thereof", you will find out eventually that some people just do not get it even after programming in Perl (or any other profession for that matter) for many years. Learn from their mistakes as well as your own.
There is a time and place for trying out your recent Perl discoveries.
That said, code that is destined to be released into production is not the place to practice your new found knowledge of hash slices.
Perl idioms are our friends.
are more widely understood? (See foreach loops.)
Whitespace is too.
This (shamelessly stolen and slightly modified) line of code
is just dying for some whitespace (unless of course you really are Writing highly obfuscated code in Perl).
Double (or even triple) check your data.
I cannot tell you how many times some new code was added that introduced a bug or that I have received a bug fix that was not needed simply because the person was using invalid data.
Remember what I said about idioms earlier? A programmer had introduced a bug when they tried to use the hash slice instead of the idiom. The data (as output by Data::Dumper) looked something like this:
When it should have looked like this:
What bug caused it?
Note that the closing parenthesis doesn't follow the 1 but @array. The programmer did not check the data that was created. He simply assumed it was correct (which leads me to my next point).
Do not assume anything.
Throughout our lives we make assumptions about all sorts of things like the weather ("I better take the umbrella. Based on the look of those clouds it's going to rain."), traffic patterns ("It's Friday. I better not take the highway or I'll be late for work!"), et cetera. Sometimes we are right and sometimes we are wrong.
Be lazy but do not take shortcuts.
Do not take the easy way out by assuming your data or code is correct. Do not skip testing things because you would rather be doing some thing else. Shortcuts lead to mistakes which lead to more time spent debugging.
Be lazy in a good way. Make use of the tools at hand (like CPAN) to save coding time and effort. Do it right the first time even if it takes a little longer now. You will save more time in the long run.
Get a "code bear".
I am not sure where I first heard about this technique but it seems to work for everyone. Pick something other than a real person and thoroughly explain the problem at hand. Your "code bear" can be a stuffed animal, a mirror, your pet gerbil or even a picture of Nikki Cox. (You know who you are! ;-) For example, my "code bear" is a stuffed animal that my wife gave me for Valentine's day this year.
The idea is a simple one: completely express your thoughts out loud. Explain the problem with as much detail as you would when speaking with a peer. In most cases, the act of putting the problem into words will get your brain cranking enough to solve the problem without wasting the time of an already overworked (and usually underpaid) co-worker. If you have not figured it out by this point then by all means discuss it with someone who can help.
Use every available resource.
By now some of you are probably saying to yourself, "This guy has put way too many links in this node. He must be nuts!" Normally I would agree with you but not this time. I put them in here to make a point.
How many times have you heard someone say something like this? "I checked my Perl pocket guide but I couldn't find what I was looking for." or "I thought that you could do X with Perl but I can't get it to work. Can you help?"
There is a wealth of information that is only a few clicks and keystrokes away. You do not have to limit yourself to just PerlMonks either. Check out http://search.cpan.org, http://www.perldoc.com, http://www.perl.org (this last one has links to just about every Perl resource you could possibly need), et cetera.
No need to limit yourself to online resources either! Go out and buy some books. Go to the library and check out some books too.
This is not an exhaustive listing by any means but some of the things that I have encountered most often. What are some of the best practices that you have learned?
Many thanks to ybiC! He spent a considerable amount of time reading this and offering feedback on how to make it better. I would also like to thank the rest of the reviewers (DigitalKitty and mojotoad spring to mind but I'm sure there were others).
Update: I'm in the process of updating the links that the ones that are pretty much random actually point to a relevant place.