So much constructive feedback, and thankfully I don't agree with all of it ;-).

Here is a combined response --

meritsOfCamelCase: Coding is personal in nature. One coder's wonderfulSolution is another coder's stuff_of_nightmares. I happen to like camelCase from the time that I first started learning how to program using Hypertalk. The real point though is not casing, but distinguishing vars from subs. QM mentioned in 464953 that &subs already have their own sigils so there is no confusion. Additionally, suffixing sub calls with parentheses() is also good practice and provides visual feedback. I find, however, that in a large-ish mess of code, camelCase vs. all_lower_case helps even more, sigils notwithstanding.

while (1) {
  my $msg_cnt = $imap->message_count($FOLDER_INBOX);
  if ($msg_cnt) {.
    
    my $dbh = connectToDb();
    
    $imap->select($FOLDER_INBOX);
    for my $msg_num (1..$msg_cnt) {
      my $this_msg;
      eval {
        $this_msg = $imap->body_string($msg_num) or die;
      };
      my $dt = getCurrentDateTime();
      if ($@) {
        my $log = "$dt: Error: $@\n";
        print "$log" if ($DEBUGGING or $CHATTY);
        print LOG "$log" if (not $DEBUGGING);
      } else {
        if (msgIsEndOfDayAudit('msg' => $this_msg)) {
          forwardMsg(..);
          eval {
            moveMsgTo('msgnum' => $msg_num, 'folder' => $FOLDER_SEEN);
          };
        } else {
          my $info = extractRecFromMsg('msg' => $this_msg);
            ..
            more code
            ..
  }
  goToSleep($SLEEPTIME);
}
[download]

That said, modify my rule #8 to "optional: subroutines named in some way to distinguish them visually from vars."

Forsaken's advice is simple, and actually makes a lot of sense to me -- since most of the vars are likely to be local to a sub, why not just name them normally without any of my this_ or local_ nonsense, but instead, the global, lexical vars might be better named with some identifying prefix. That way, within a sub I will know immediately what is a "global lexical" vs. "local to the sub."

So, flip rules #4 and #5 around.

However, #3 doesn't make #5 redundant. Package vars are in ALL_CAPS, but everything else can still be lexical as well as local... hence the need for distinguishing the package vars, the (package) lexicals, and the sub locals from each other.

ikegami says that sigil+pluralization already disambiguates references from non-references. Fair enough, but different types of references don't get disambiguated. Hence, looking at $pearls, it is not clear if it is a ref to an array or a sub or a hash. Hence, the need for 'aref_', 'href_', or 'sref_' (or whatever). Additionally, there could be legitimately pluralized scalars which could lead to further confusion (for example, if I wanted to hold the number of pearls in $pearls). I must add, as an additional rule, that I pluralize the arrays and hashes, and singularize the elements. Hence, @pearls versus $pearl = $pearls[3].

I would add merlyn's advice to my list of rules -- "jit declaration and init" as much as possible.

A question to the architects of the language (TimToady, if you read this). When, as merlyn says, (and I agree), Programming with globals is so 80's, why does Perl not have all vars as local in scope unless declared global explicitly. Is it because Perl was invented in the 80's {grin}? I hate to bring up the example of PHP (a language that I don't particularly care for), but it makes everything in a sub local to it unless an outside var is brought in as a global explicitly. Perhaps, the dot notation of Perl6 might solve most of the above-mentioned, scoping-related problems.

Janitorial note: I posted this on SoPW because I was seeking perl wisdom, not really meditating. I hope newcomers to Perlmonks and, to Perl itself, visit the meditations enough to read all the good stuff there (I should do more, but I end up spending most of my time on SoPW).

Many thanks everyone.

update: The way I look at it, I almost wish Perl would allow me to make my own sigils... in effect, that is what I trying to accomplish with all my prefixing nonsense above. Being able to make my own sigils in addition to the company-provided $, @, and % would be very cool.

update2: rule 10. Always pass named variables to subs (as in the code example above).