Являются ли кавычки вокруг хеш-ключей хорошей практикой в ​​Perl?

Question

Стоит ли заключать в кавычки ключи при использовании хэша в Perl?

Я работаю над чрезвычайно большой унаследованной базой кода Perl и пытаюсь перенять множество лучших практик, предложенных Дамианом Конвеем в Perl Best Practices . Я знаю, что лучшие практики - всегда - очень деликатный вопрос для программистов, но, надеюсь, я смогу получить хорошие ответы на этот вопрос, не начав войны с пламенем. Я также знаю, что это, вероятно, что-то, о чем многие люди не будут спорить, потому что это незначительная проблема, но я пытаюсь получить твердый список руководств, которым нужно следовать, когда я пробираюсь через эту базу кода.

В книге Perl Best Practices Дамиана Конвея есть этот пример, который показывает, как выравнивание помогает читабельности фрагмента кода, но не упоминает (где-нибудь в книге, которую я могу найти ) что-нибудь о цитировании хеш-ключей.

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

Не лучше ли написать кавычки, чтобы подчеркнуть, что вы не используете голые слова?

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

Answer 1

Без кавычек лучше. Он находится в {}, поэтому очевидно, что вы не используете голые слова, плюс его легче читать и печатать (на два символа меньше). Но все это, конечно, зависит от программиста.

Answer 2

При указании константных ключей хеш-строки всегда следует использовать (одинарные) кавычки. Например, $hash{'key'} Это лучший выбор, потому что он устраняет необходимость думать об этой проблеме и приводит к согласованному форматированию. Если вы иногда пропускаете кавычки, не забудьте добавить их, когда ваш ключ содержит внутренние знаки переноса, пробелы или другие специальные символы. Вы должны использовать кавычки в этих случаях, что приводит к непоследовательному форматированию (иногда без кавычек, иногда в кавычках). Ключи в кавычках также с большей вероятностью будут выделены синтаксисом вашим редактором.

Вот пример, где использование соглашения «цитируемый иногда, а не цитируемый в другое время» может привести к неприятностям:

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

Это прекрасно скомпилируется в use strict, но не совсем так, как вы ожидаете во время выполнения. Хеш-ключи - это строки. Строки следует заключать в кавычки в соответствии с их содержанием: одинарные кавычки для буквенных строк, двойные кавычки для интерполяции переменных. Процитируй свои хеш-ключи. Это самое безопасное соглашение и самое простое для понимания и выполнения.

Answer 3

Я никогда не использую одинарные кеш-ключи. Я знаю, что {} в основном работает как кавычки, за исключением особых случаев (+ и двойные кавычки). Мой редактор тоже это знает и дает мне несколько подсказок по цвету, чтобы убедиться, что я сделал то, что хотел.

Использование одинарных кавычек везде кажется мне «защитной» практикой, совершаемой людьми, которые не знают Perl. Сохраните немного износа клавиатуры и изучите Perl:)

Из-за разглагольствования, настоящей причины, по которой я публикую этот комментарий ... другие комментарии, похоже, упустили тот факт, что + "процитирует" голое слово. Это означает, что вы можете написать:

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

или

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

Итак, совершенно очевидно, что +shift означает «вызов функции сдвига», а shift означает «строку 'shift" ".

Я также укажу, что cperl-mode правильно выделяет все различные случаи. Если это не так, пингуйте меня по IRC, и я исправлю это:)

(Да, и еще одна вещь. Я цитирую имена атрибутов в Moose, как в has 'foo' => .... Это привычка, которую я приобрел, работая со Стеваном, и хотя я думаю, что это выглядит хорошо ... немного несовместим с остальной частью моего кода. Может быть, я перестану делать это в ближайшее время.)

Answer 4

Хэш-ключи без кавычек получили внимание на уровне синтаксиса от Ларри Уолла, чтобы удостовериться, что для них не будет никаких оснований, кроме передового опыта. Не парьтесь с цитатами.

(Между прочим, кавычки на ключах массива являются лучшей практикой в ​​PHP, и может быть серьезное последствие отказа от их использования, не говоря уже о тоннах E_WARNING. Хорошо в Perl! )

Answer 5

Не думаю, что в этом есть лучшая практика. Лично я использую их в хеш-ключах так:

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

, но не используйте их слева от оператора стрелки:

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

Не спрашивайте меня, почему, просто я так делаю :)

Я думаю, что самое важное, что вы можете сделать, это всегда, всегда, всегда:

use strict;
use warnings; 

Таким образом, компилятор будет отлавливать любые семантические ошибки для вас, оставляя вам меньше шансов ошибиться, что бы вы ни выбрали

И вторая по важности вещь - быть последовательным.

Answer 6

Я иду без кавычек, просто потому, что меньше набирать, читать и беспокоиться. Времена, когда у меня есть ключ, который не будет автоматически цитироваться, очень редки, чтобы не стоить всей дополнительной работы и беспорядка. Возможно, мой выбор хеш-ключей изменился, чтобы соответствовать моему стилю, что также хорошо. Избегайте крайних случаев полностью.

По той же причине я использую " по умолчанию. Для меня более распространено выводить переменную в середине строки, чем использовать символ, который я не хочу интерполировать. То есть я чаще писал 'Hello, my name is $name', чем "You owe me $1000".

Answer 7

По крайней мере, кавычки предотвращают выделение синтаксиса зарезервированных слов в не очень совершенных редакторах. Проверить:

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

Answer 8

Я предпочитаю идти без кавычек, если не хочу некоторой интерполяции строк. И тогда я использую двойные кавычки. Я сравниваю это с буквальными числами. Perl действительно позволит вам сделать следующее:

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

Но никто этого не делает. И это не помогает с ясностью, просто потому что мы добавляем еще два символа для ввода. Так же, как иногда мы специально хотим слот № 3 в массиве, иногда мы хотим, чтобы запись PATH была из %ENV. Насколько мне известно, в одиночных кавычках добавлена ​​ нет ясности.

То, как Perl анализирует код, делает невозможным использование других типов «голых слов» в хеш-индексе.

Попробуйте

$myhash{shift}

и вы собираетесь получить элемент, хранящийся в хэше под ключом 'shift', вам нужно сделать это

$myhash{shift()}

, чтобы указать, что вы хотите, чтобы первый аргумент индексировал ваш хэш.

Кроме того, я использую jEdit , визуальный редактор ONLY (который я видел - кроме emacs), который позволяет you полный контроль над подсветкой , Так что это вдвойне понятно для меня. Все, что похоже на первое, получает KEYWORD3 ($ myhash) + SYMBOL ({) + LITERAL2 (shift) + SYMBOL (}), если перед закрывающим фигурным скобками есть парантез, он получает KEYWORD3 + SYMBOL + KEYWORD1 + SYMBOL (()}). Кроме того, я, скорее всего, отформатирую это так:

$myhash{ shift() }

Answer 9

Перейти с цитатами! Они визуально разбивают синтаксис, и больше редакторов будут поддерживать их в подсветке синтаксиса (эй, даже переполнение стека выделяет версию цитаты). Я также утверждаю, что вы заметите опечатки быстрее, когда редакторы проверят, что вы закончили свою цитату.

Answer 10

Вы также можете поставить перед клавишей «-» (минус символ), но имейте в виду, что это добавляет «-» к , начинающемуся вашего ключа. Из моего кода:

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

Я тоже использую одинарные, двойные и без кавычек. Все в одной программе: -)