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';

Solution 1

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.

Solution 2

Without quotes is better. It's in {} so it's 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.

Solution 3

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.)

Solution 4

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.)

Solution 5

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.

View more solutions