malaga has asked for the
wisdom of the Perl Monks concerning the following question:

i am just finishing up my first 100% perl contract, and with the help of a lot of people on this site, i did very well. i only have one day left, but before i leave the company, i want to go over my scripts and make sure i haven't done anything, (or omitted anything) that i shouldn't have. i want to be sure i've done a professional job. does anyone have or know where to find guidelines for this purpose?

I'm not sure if there are any guidelines for something like that.. usually make your own checklist. But, you may want to make sure that your code is well commented - so that others that inherit your programs will be able to understand what you're doing. Just sometimes useful - make sure that documentation is complete.

I think the big picture for professionalism in coding goes something like this:

Clear and Consistent Code Design

Documented

Secure

Before I launch a perl project for a client, I add a standard header to all the files, that includes it's name, a short description, a version, and basic info on the license, contact info, and an abbreviated ChangeLog of major changes to the script.

As for "good style", that's a sort of elusive and fuzzy thing. I enjoyed reading the The Practice of Programming which relates to that topic.

As for security, I'm sure you can find a webpage on secure perl programming to measure your work against.

Also, there's nothing like good old peer review to improve code. Perhaps there's a co-worker who would be willing to look things over?

If you can make sure the script runs under taint mode
(it isn't just for CGIs!), then you've taken a significant
step towards making your script secure. Taint mode
(-T on the command or '#!' line) isn't a magic bullet,
though. It can stop you from making some subtle mistakes, like using
unexamined user input in eval or system (not just system) calls.
See perldoc perlsec for more.

You should check that your code fails gracefully, too. That was a really hard one for me to learn- I wrote code that had all kinds of silly dependecies (servers being kept up by other people's personal cron jobs, report files being available in random places, etc), and then forgot about the scripts. When the script would start randomly failing because something it had depended on changed, it would take me forever to track down the problem. I try to be really paranoid now, and wrap stuff in evals, check return codes from system calls, & write error strings that make sense. It's good to not have to explain to people that you have no clue why your tool started failing over weekend & that you'll have to get back to them in a day or two. Although I guess that if you're leaving, you won't have to deal with that part. (:

It's really hard to make the adjustment from hacking code for your CS homework or your own website to writing code that people depend on to do work, though. I'm always finding new things that I should be doing & becoming embarassed that I hadn't been doing them before. -- cat

It looks to me as though you're making a very common "professional" mistake.

The mistake is this: you've not answered the question "professional to whom?" Instead, you're substituting your own definition, augmented by the opinions of semi-random strangers. Now having a strong sense of professionalism and values is a Very Good Thing, but when you're taking someone else's money, you need to work to their definition. (If you don't agree with and can't abide their definition of "professionalism", don't take the job.)

It may be a little late in the game for you to ask, but have you determined what the people on the other end of the contract consider to be a "professional job"? If they're big on written doc, focus there. If they're big on unit tests, focus there. You get the idea.

(Update: On re-read, my tone may be a bit condescending. Not my intent. This particular mistake is one I have lots of first-hand experience with. --dws)

There are a lot of good comments and tips in this thread
for you to apply, not least of which is the one from dws about
being fully aware of the client's needs and specifications
at all times.

While it's a bit late for your current job, I'd like to add that all these
things should be part of your modus operandi at all
times, from before you've got the job (if you don't clearly
understand the client you may well not get the work, or you
may get it not realizing what you're in for), right through
to completion. It is good that you've set aside time at
the end, but really this quality control must be incorporated
all along.

thanks for the criticisms too. i do know the expectations of this employer and i do have a professional opinion of my own (this is my first 100% perl job - not my first job!). i don't have a written checklist list yet, but i am working on one now because I think it's a good place to start for future work. i posted this here to see what i might not have thought of (nothing new came up, but i liked reading about how others think the subject through. and if there were some great checklist in the sky i would certainly want to know about it.) This is one very good resource, even if you are strangers :)

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other