I did not really learn everything I know about Perl from Kurt Starsinic (Randal Schwartz gets that distinction :), but it was not until we started to work together that I started to keep track of the things I learned, mostly from debugging modules. All of these tips comes from real-life mistakes I personally made and Kurt from time to time helped me discover:
- Keys don't show up in hashes unless I create them
- Arrays don't have anything in them until I add elements to them.
- If I assign a scalar a new value that it shouldn't have, it no longer has the value it should have.
- If I want to use the DBI module, I need to install it.
- If I modify a reference, the data changes.
- If I want to call the subroutine foo(), I shouldn't spell it "bar".
- "true" is always numerically equal to "false"
- "true" is always numerically equal to undef
- If I assign a value to a string, it replaces the old value rather than appending to it (lesson: .= is not the same as =).
- I can't expect Perl to load CGI.pm just because I say CGI->new(). (But wouldn't that be cool!)
- A script still acts broken unless I save the changes.
- mod_perl modules still act broken unless it reloads the modules.
- CVS still has the old version until I commit the changes (which means everyone else has the old changes).
- If I ssh to a remote machine and take down the network interface, I cannot ssh to the machine to bring it back up (took me three tries to learn this one---lesson: terminal servers good! brian sysadmin bad!).
- Regular expressions don't match anything in a null string in a variable name I spelled incorrectly.
- strict doesn't work unless I use it (see prior tip).
- Although Perl lets me use really long names, I shouldn't create variables like $this_client_really_sucks_and_will_never_see_this_code = 6 (true story---actually did that and someone sent it to the client without looking at it).
- Don't make changes after code freeze and right before Randal reviews the code. He'll bust me on it (and has) because it almost is always bad code.
- Tests don't run unless I create them.
- Warnings don't go away if I just keep running the script (although if Perl were upgraded...).
- unlink returns the number of files I need to restore from backup, but not their names.
- If I muck with the Perl source and don't tell anyone and they recompile a perl for themselves, their perl probably won't work.
- Always grab clean sources (see prior tip).
- Always muck with sources in your own directory, not the stuff in /usr/src.
- If I don't make the cable a cross-over cable, it doesn't act like a cross-over cable.
- I must be connected to the network to fetch pages with LWP (wouldn't it be cool if all these wires went away...oh wait, they did!)
- Perl programs that I think will run fast don't and ones that I think will run slowly do.
- If I write a Python construct in a Perl script, Perl will give me an error (unless I use one of them fancy Damian modules).
- Files aren't easier to open the 40th time I try (lesson: the directory has to exist---check $!).
- Don't trust programs that compile on the first shot (all those syntax errors turned into logic errors).
And, the most important lesson I learned about using Perl:
- Wait three days to tell them I'm done, even if I wrote the script in 15 minutes.
