Naming

Damian discusses some techniques in Perl Best Practices. Larry has some advice in perlstyle.

There are various naming conventions you can use, and don't restrict yourself to Perlville to find one that makes sense for you and what you are doing.

• You probably don't want to completely invent your own style because good programmers will already know the basic conventions of the major styles out there. Small deviations aren't that bad, but something completely wacky will distract the code reader from the really important stuff.
• DOS was a long time ago. You can use more than eight characters. What did vowels ever do to you, anyway? :)
• Remember that names that make sense to you only do so because you picked them. Abbreviations, for example, might not make sense to someone who doesn't speak your language as their first language.
• Whatever you do, be consistent. Make other people who edit the code be not only self-consistent, but project consistent too.
• Use the same names (because hey, they're all lexicals, right?) to mean the same thing everywhere in the code, even if it's in different files that have nothing to do with each other. For instance, if you use $email to mean the email address, don't call the same idea $address or $to somewhere else.
• Make similar ideas have similar names, such as $from_email<code>, <code>$to_email; or always appending _dbh to database handle names or C_fh and so on. This isn't just about things that go together (you probably want to put those in a hash :), but marking the same idea the same way each time so code readers can take what they learned from your code elsewhere and use it to understand new code.
• Spell out words for important variables ($count instead of $cnt), although very short term variables or widely used names ($i for an index, $fh for a filehandle) may break this rule.
• When interacting with a module, I try to use the same variables from its examples, such as $dbh, $sth, and so on from DBI.
• I tend to use all lowercase for normal variable names, initial caps for globals (package vars), and all uppercase for constants.

Other monks probably will chime in with more advice, and I'm off to eat thanksgiving turkey or I'd think about this more. Good luck :)

Declarations

I tend to define the lexical variables as late as possible and as close to their use as possible, as in your first example. This limits the effect of the variable to exactly the scope I want to use it. If I need it in some other scope, I just declare it again.

Declaring variables upfront tends to give variables a larger scope than they really need. You might do that as a way to start introducing lexical variables into a script that only used package variables, but only while you waited for the time to convert them to your first form.