update: as demonstrated by ikegami below, actually only valid identifiers are quoted: that means anything matching /^[a-zA-Z_]\w*$/ but not numbers.

As long as you use valid keys, and don't use version strings (/^v\d+$/) the quoted and unquoted keys are equivalent.

The version strings implementation makes $hash{v80} != $hash{'v80'} etc. in some versions of perl, so for portability these keys should always be quoted.

So, in short, if you don't want to think about the keys you use, quote them, but usually an intuitive key name can be used unquoted.

automatically quoted strings [...] more or less matching /^([1-9]\d*)|([a-zA-Z_]\w*)$/

No, it doesn't match numbers at all. If => autoquoted numbers, the key would be a bunch of 9s in the example below. Non-strings (numbers, references, etc) are converted to strings (although I think there is planned change to preserve the type of the key, maybe in perl6), but that's not the same as quoting. I think that means that if and only if it's a valid subroutine name, it'll get autoquoted.

>perl -le "
   %a = (999999999999999999999999999999999999 => '');
   print keys %a";
1e+036

>perl -le "
   %a = (999999999999999999999999999999999999, '');
   print keys %a";
1e+036
[download]

Hmmm. You're right. I think my confusion stems from the fact that "regular" numbers (a couple of digits not starting with 0) will work the same as the quoted version.

Joost.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

See some interesting discussion on this subject at Coding superstitions (and especially mstone's contribution).

Why do you say that your first examples are better? I don't see why they are better.

Of course, with your second examples, it's important to know the quoting rules for a) the "fat comma" and b) hash index braces.

They are equivalent, aren't they? Where is it said that quoting the key is better?

(Of course, if your key contains symbols or whitespace or something, then you have to quote it.)

I've had people correct me on some posts in the past without explanation so I just decided to ask.
But the piont about white space makes sense.

Thanks for your help.

I almost always prefer the quote-less versions. You do have to understand the quoting rules to read them, but I still prefer them. Quoting everything explicitly can make code look really busy, particularly when there are a lot of key-value-pairs. It makes for a lot of clutter. Using the fat comma makes things much calmer.

Also, I use a syntax highlighting editor, which I consider to have been quite beneficial to my coding style in general. In this case, the highlighting reminds me that the bits I'm looking at are actually strings. It also encourages me to disambiguate function calls explicitly, for my own benefit, because the highlighting needs the cues to pick up the difference.

In older versions of perl, there was at least one good reason to prefer $hash{'name'} to $hash{name}. Observe:

$ perl -v
This is perl, version 5.004_04 built for sun4-solaris

$ perl -lwe 'use strict; sub ambiguous { } my %hash; $hash{ambiguous}=
+5; print "but not fatal"'
Ambiguous use of {ambiguous} resolved to {"ambiguous"} at -e line 1.
but not fatal
[download]

So, if you're really worried about backwards compatibility (or, as in my case, you're stuck using an old perl via a CGI server), it might be beneficial to use the quotes. (I can't tell exactly, but it looks like this was fixed in 5.005_something)

Update: what kwoff said: better example of CGI-related error that not-quoting leads to.

The unquoted strings (a.k.a. "bareword strings") are ambiguous. If, for some strange reason, the Perl interpreter decides to interpret name as a function or somesuch, there could be logic bugs. So, some consider it good practice merely to quote all bareword strings (hash keys included) simply to promote readability and "take no risks".

The fact of the matter is, though, that the likelihood of a bareword being confusing to the interpreter and not generating a warning or error -- even in future Perl releases -- is fantastically small. So, don't worry about it!

In any case, just pick one and be consistent. If you think quoted strings are better in place of barewords, go ahead and use them -- just use them in every case. Consistency makes for far more readable (and maintainable) code than adherance to anyone else's ideas of "right code".

If, for some strange reason, the Perl interpreter decides to interpret name as a function or somesuch

But it doesn't decide "for some strange reason". That sounds as if it was a matter dependent on rolling dice. The decision is actually deterministic and comprehensible.

Makeshifts last the longest.

I see you mistook my meaning. I was speaking of Perl the person. :P (Or, rather, Perl as a community).
^{--
$me = rand($hacker{perl});}

my($count)=0;
sub name() {'autoname'.$count++}

$foo{name}='bob';
[download]

That doesn't have anything to do with quoting keys. $foo{name} will always be interpreted as $foo{'name'}, and there's no way you can disambiguate that by using or not using quotes.

If that was supposed to call your name function, you should have written it with parens, as in $foo{name()}. In fact, you should get in the habit of never calling functions without parens. (And of using sub strictures.) That will disambiguate almost every case of possible confusion that crops up in Perl.

Makeshifts last the longest.

In Perl 6, acording to the currently most recent documents, bareword keys will be an error. That's why I have started quoting my hash keys. I want to be 18 months ( 36 months ) ( 48 months ) ahead of the rest of you.