Some things that I consider "best pratices":

• Always use strict; and use warnings; (or -w if you're using perl <5.6). If you do somthing that breaks a warning or stricture, use a no that lets you brake just that one, and in the tightest scope possible.
• Write your code to be reusable.
• Write your code to handle at least twice the biggest dataset you expect to ever be handed to it.
• Expect the project to become more complicated as you are working on it.
• If you think of somthing while writing that you could do better, but don't have time to do it that way, comment.
• Comment on input and output of subs at the top of the sub. If the input is a file containing data in a format, comment on it.
• If you write somthing one way, and then have to go back to it to fix a subtle problem, comment on it, because otherwise you may be tempted to go back later, and end up changeing it back to exactly what it was before.

Note that best pratices are different when you're writing code for different purposes. I generaly exepect to be the only one who needs to follow my code; that's the environment I work in. Similarly, most of my code is throwaway. That doesn't mean I don't code in reusable subs -- I often find that also makes my code easier to change later when I have to make it do more later. To answer the question posed in the subject, though, which is different: I consider good code to be code that is produced that does what it needs to do, was produced within schedule and budget, and is readable and work-with-able by the people who need to work with it. Note that I say "what it needs to do", not "what it was spec'd to have to do".