Are quotes around hash keys a good practice in Perl?

Question

Is it a good idea to quote keys when using a hash in Perl?

I am working on an extremely large legacy Perl code base and trying to adopt a lot of the best practices suggested by Damian Conway in Perl Best Practices. I know that best practices are always a touchy subject with programmers, but hopefully I can get some good answers on this one without starting a flame war. I also know that this is probably something that a lot of people wouldn't argue over due to it being a minor issue, but I'm trying to get a solid list of guidelines to follow as I work my way through this code base.

In the Perl Best Practices book by Damian Conway, there is this example which shows how alignment helps legibility of a section of code, but it doesn't mention (anywhere in the book that I can find) anything about quoting the hash keys.

$ident{ name   } = standardize_name($name);
$ident{ age    } = time - $birth_date;
$ident{ status } = 'active';

Wouldn't this be better written with quotes to emphasize that you are not using bare words?

$ident{ 'name'   } = standardize_name($name);
$ident{ 'age'    } = time - $birth_date;
$ident{ 'status' } = 'active';

Answer 1

Without quotes is better. It's in {} so its obvious that you are not using barewords, plus it is both easier to read and type (two less symbols). But all of this depends on the programmer, of course.

Answer 2

Quoteless hash keys received syntax-level attention from Larry Wall to make sure that there would be no reason for them to be other than best practice. Don't sweat the quotes.

(Incidentally, quotes on array keys are best practice in PHP, and there can be serious consequences to failing to use them, not to mention tons of E_WARNINGs. Okay in Perl != okay in PHP.)

Answer 3

It is better with quotes because it allows you to use special characters not permitted in barewords. By using quotes I can use the special characters of my mother tongue in hash keys.

Answer 4

Go with the quotes! They visually break up the syntax and more editors will support them in the syntax highlighting (hey, even stackoverflow is highlighting the quote version). I'd also argue that you'd notice typos quicker with editors checking that you ended your quote.

Answer 5

At least, quoting prevent syntax highlighting reserved words in not-so-perfect editors. Check out:

$i{keys} = $a;
$i{values} = [1,2];
...

Answer 6

I don't think there's a best practice on this one. Personally I use them in hash keys like so:

$ident{'name'} = standardize_name($name);

but don't use them to the left of the arrow operator:

$ident = {name => standardize_name($name)};

Don't ask me why, it's just the way I do it :)

I think the most important thing you can do is to always, always, always:

use strict;
use warnings;

That way the compiler will catch any semantic errors for you, leaving you less likely to mistype something, whichever way you decide to go.

And the second most important thing is to be consistent.

Answer 7

When specifying constant string hash keys, you should always use (single) quotes. E.g., $hash{'key'} This is the best choice because it obviates the need to think about this issue and results in consistent formatting. If you leave off the quotes sometimes, you have to remember to add them when your key contains internal hypens, spaces, or other special characters. You must use quotes in those cases, leading to inconsistent formatting (sometimes unquoted, sometimes quoted). Quoted keys are also more likely to be syntax-highlighted by your editor.

Here's an example where using the "quoted sometimes, not quoted other times" convention can get you into trouble:

$settings{unlink-devices} = 1; # I saved two characters!

That'll compile just fine under use strict, but won't quite do what you expect at runtime. Hash keys are strings. Strings should be quoted as appropriate for their content: single quotes for literal strings, double quotes to allow variable interpolation. Quote your hash keys. It's the safest convention and the simplest to understand and follow.

Answer 8

I prefer to go without quotes, unless I want some string interpolation. And then I use double quotes. I liken it to literal numbers. Perl would really allow you to do the following:

$achoo['1']  = 'kleenex';
$achoo['14'] = 'hankies';

But nobody does that. And it doesn't help with clarity, simply because we add two more characters to type. Just like sometimes we specifically want slot #3 in an array, sometimes we want the PATH entry out of %ENV. Single-quoting it add no clarity as far as I'm concerned.

The way Perl parses code makes it impossible to use other types of "bare words" in a hash index.

Try

$myhash{shift}

and you're only going to get the item stored in the hash under the 'shift' key, you have to do this

$myhash{shift()}

in order to specify that you want the first argument to index your hash.

In addition, I use jEdit, the ONLY visual editor (that I've seen--besides emacs) that allows you total control over highlighting. So it's doubly clear to me. Anything looking like the former gets KEYWORD3 ($myhash) + SYMBOL ({) + LITERAL2 (shift) + SYMBOL (}) if there is a paranthesis before the closing curly it gets KEYWORD3 + SYMBOL + KEYWORD1 + SYMBOL (()}). Plus I'll likely format it like this as well:

$myhash{ shift() }

Answer 9

You can precede the key with a - (minus character) too. From some of my code:

$args{-title} ||= "Intrig";

I use the single quote, double quote, and quoteless way too. All in the same program :-)

Answer 10

I've always used them without quotes but I would echo the use of strict and warnings as they pick out most of the common mistakes.

Answer 11

I've wondered about this myself, especially when I found I've made some lapses:

 use constant CONSTANT => 'something';
 ...
 my %hash = ()
 $hash{CONSTANT}          = 'whoops!';  # Not what I intended
 $hash{word-with-hyphens} = 'whoops!';  # wrong again

What I tend to do now is to apply quotes universally on a per-hash basis if at least one of the literal keys needs them; and use parentheses with constants:

 $hash{CONSTANT()} = 'ugly, but what can you do?';

Answer 12

I go without quotes, just because it's less to type and read and worry about. The times when I have a key which won't be auto-quoted are few and far between so as not to be worth all the extra work and clutter. Perhaps my choice of hash keys have changed to fit my style, which is just as well. Avoid the edge cases entirely.

Sort of the same reason I use " by default. It's more common for me to plop a variable in the middle of a string then to use a character that I don't want interpolated. Which is to say, I've more often written 'Hello, my name is $name' than "You owe me $1000".

Answer 13

I never single-quote hash keys. I know that {} basically works like quotes do, except in special cases (a +, and double-quotes). My editor knows this too, and gives me some color-based cues to make sure that I did what I intended.

Using single-quotes everywhere seems to me like a "defensive" practice perpetrated by people that don't know Perl. Save some keyboard wear and learn Perl :)

With the rant out of the way, the real reason I am posting this comment...the other comments seem to have missed the fact that + will "unquote" a bareword. That means you can write:

sub foo {
    $hash{+shift} = 42;
}

or:

use constant foo => 'OH HAI';
$hash{+foo} = 'I AM A LOLCAT';

So it's pretty clear that +shift means "call the shift function" and shift means "the string 'shift'".

I will also point out that cperl-mode highlights all of the various cases correctly. If it doesn't, ping me on IRC and I will fix it :)

(Oh, and one more thing. I do quote attribute names in Moose, as in has 'foo' => .... This is a habit I picked up from working with stevan, and although I think it looks nice... it is a bit inconsistent with the rest of my code. Maybe I will stop doing it soon.)