Les guillemets autour des clés de hachage sont-ils une bonne pratique en Perl?

Question

Est-ce une bonne idée de citer des clés lorsque vous utilisez un hachage dans Perl?

Je travaille sur une base de code Perl héritée extrêmement importante et j'essaie d'adopter un grand nombre des meilleures pratiques suggérées par Damian Conway dans Meilleures pratiques Perl . Je sais que les meilleures pratiques sont toujours un sujet délicat pour les programmeurs, mais j'espère pouvoir obtenir de bonnes réponses à ce sujet sans déclencher une guerre des flammes. Je sais aussi que c’est probablement une question que peu de gens discuteraient, car c’est un problème mineur, mais j’essaie d’obtenir une liste complète de directives à suivre tout au long de ce code.

Dans le livre sur les pratiques optimales Perl de Damian Conway , cet exemple montre comment l'alignement peut aider la lisibilité d'une section de code, mais elle ne mentionne pas (où que je puisse trouver dans le livre) quoi que ce soit à propos de la citation des clés de hachage.

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

Ne serait-il pas préférable d'écrire des citations pour souligner le fait que vous n'utilisez pas de mots nus?

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

Answer 1

Lorsque vous spécifiez des clés de hachage à chaîne constante, vous devez toujours utiliser des guillemets (simples). Par exemple, $ hash {'key'} C'est le meilleur choix car il évite de penser à ce problème et donne lieu à un formatage cohérent. Si vous oubliez parfois les guillemets, n'oubliez pas de les ajouter lorsque votre clé contient des caractères internes, des espaces ou d'autres caractères spéciaux. Vous devez utiliser des guillemets dans ces cas, ce qui entraîne une mise en forme incohérente (parfois sans guillemets, parfois entre guillemets). Les clés citées sont également plus susceptibles d'être mises en évidence par la syntaxe par votre éditeur.

Voici un exemple d'utilisation de l'expression "parfois cité, mais pas d'autre fois" convention peut vous causer des ennuis:

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

Cela se compilera très bien sous use strict , mais ne fera pas tout à fait ce que vous attendez au moment de l'exécution. Les clés de hachage sont des chaînes. Les chaînes doivent être citées en fonction de leur contenu: guillemets simples pour les chaînes littérales, guillemets doubles pour permettre une interpolation de variable. Citez vos clés de hachage. C’est la convention la plus sûre et la plus simple à comprendre et à suivre.

Answer 2

Sans guillemets, c'est mieux. Il est évident que vous n'utilisez pas de mots nus, il est en outre plus facile à lire et à taper (deux symboles de moins). Mais tout dépend du programmeur, bien sûr.

Answer 3

Je ne cite jamais une seule clé de hachage. Je sais que {} fonctionne fondamentalement comme les guillemets, sauf dans des cas spéciaux (a + et guillemets). Mon éditeur le sait aussi et me donne des repères basés sur les couleurs pour m'assurer que j'ai bien fait ce que je voulais.

L’utilisation de guillemets simples partout me semble être une option "défensive". pratique perpétrée par des personnes qui ne connaissent pas Perl. Économiser de l'usure du clavier et apprendre Perl:)

Après le coup de gueule, la vraie raison pour laquelle je poste ce commentaire ... les autres commentaires semblent avoir oublié le fait que + va "ne pas citer de citations". un mot simple. Cela signifie que vous pouvez écrire:

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

ou:

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

Il est donc assez clair que + shift signifie "appeler la fonction shift". et shift signifie "la chaîne 'shift'".

Je ferai également remarquer que le mode cperl met correctement en évidence tous les cas. Si ce n'est pas le cas, envoyez-moi une requête ping sur IRC et je le corrigerai:)

(Oh, et encore une chose. Je cite les noms d'attributs dans Moose, comme dans a 'foo' = > ... . C'est une habitude que j'ai prise en travaillant avec stevan , et même si je trouve que ça a l'air sympa ... c'est un peu incohérent avec le reste de mon code, je vais peut-être arrêter de le faire bientôt.)

Answer 4

Les clés de hachage Quoteless ont reçu l’attention de Larry Wall au niveau de la syntaxe pour s’assurer qu’il n’y avait aucune raison de les utiliser comme meilleure pratique. Ne pas transpirer les guillemets.

(Incidemment, les guillemets sur les clés de tableau sont les meilleures pratiques en PHP. Si vous ne les utilisez pas, cela peut avoir de graves conséquences, sans parler de tonnes de E_WARNINGs. Bon en Perl! = bien en PHP .)

Answer 5

Je ne pense pas qu'il existe une meilleure pratique pour celui-ci. Personnellement, je les utilise dans les clés de hachage comme ceci:

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

mais ne les utilisez pas à gauche de l'opérateur de flèche:

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

Ne me demandez pas pourquoi, c'est juste comme je le fais:)

Je pense que la chose la plus importante à faire est de toujours, toujours, toujours:

use strict;
use warnings; 

De cette façon, le compilateur détectera les erreurs sémantiques pour vous, ce qui vous laissera moins susceptible de taper quelque chose de mal, quelle que soit la méthode choisie.

Et la deuxième chose la plus importante est d'être cohérent.

Answer 6

Je pars sans guillemets, simplement parce que c’est moins difficile à écrire, à lire et à s’inquiéter. Les moments où j'ai une clé qui ne sera pas automatiquement citée sont rares pour ne pas valoir tout le travail supplémentaire et l'encombrement. Peut-être que mon choix de touches de hachage a changé pour correspondre à mon style, ce qui est tout aussi bien. Évitez complètement les cas extrêmes.

C'est un peu la même raison pour laquelle j'utilise " par défaut. Il est plus courant pour moi de placer une variable au milieu d'une chaîne que d'utiliser un caractère que je ne souhaite pas interpoler. C’est-à-dire que j’ai plus souvent écrit 'Bonjour, mon nom est $ name' que "Vous me devez 1 000 $" .

Answer 7

Au moins, les guillemets empêchent la syntaxe de surligner les mots réservés dans les éditeurs pas si parfaits. Départ:

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

Answer 8

Je préfère les guillemets, à moins que je ne souhaite une interpolation de chaîne. Et puis j'utilise des guillemets doubles. Je compare cela à des nombres littéraux. Perl vous permettrait vraiment de faire ce qui suit:

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

Mais personne ne le fait. Et cela n’aide en rien la clarté, tout simplement parce que nous ajoutons deux caractères supplémentaires à la saisie. Tout comme parfois nous voulons spécifiquement l'emplacement n ° 3 dans un tableau, parfois nous voulons que l'entrée PATH soit issue de % ENV . La simple citation ajoute une non clarté pour moi.

La manière dont Perl analyse le code rend impossible l'utilisation d'autres types de "mots nus". dans un index de hachage.

Essayez

$myhash{shift}

et vous n'obtiendrez que l'élément stocké dans le hachage sous la touche 'shift' , vous devez le faire

$myhash{shift()}

afin de spécifier que vous voulez que le premier argument indexe votre hachage.

De plus, j'utilise jEdit , l'éditeur visuel SEULEMENT (que je vu - en plus d’emacs) qui vous permet de contrôler totalement la mise en évidence. C'est donc doublement clair pour moi. KEYWORD3 ($ myhash) + SYMBOLE ({) + LITERAL2 (shift) + SYMBOLE (}) s'il ressemble à un ancien, il y a un paranthesis avant la fermeture bouclée, il devient KEYWORD3 + SYMBOL + KEYWORD1 + SYMBOL (()}). De plus, je le formaterai probablement comme ça:

$myhash{ shift() }

Answer 9

Allez avec les citations! Ils divisent visuellement la syntaxe et de plus en plus d'éditeurs les supportent dans la coloration syntaxique (hé, même Stack Overflow met en évidence la version du devis). Je soutiendrais également que vous remarqueriez plus rapidement les fautes de frappe lorsque les éditeurs vérifient que vous avez bien terminé votre devis.

Answer 10

Il est préférable d'utiliser des guillemets, car cela vous permet d'utiliser des caractères spéciaux non autorisés dans les mots nus. En utilisant des guillemets, je peux utiliser les caractères spéciaux de ma langue maternelle dans les touches de hachage.

Answer 11

Vous pouvez faire précéder la clé d'un " - " (caractère moins) aussi, mais sachez que cela ajoute le " - " au début de votre clé. À partir de certains de mes codes:

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

J'utilise aussi les guillemets simples, les guillemets doubles et la méthode peu coûteuse. Tous dans le même programme: -)

Answer 12

Je me suis posé la question moi-même, surtout quand j'ai découvert que j'avais fait quelques fautes:

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

Ce que j’ai tendance à faire maintenant, c’est d’appliquer universellement les citations par hachage si au moins une des clés littérales en a besoin; et utilisez des parenthèses avec des constantes:

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

Answer 13

Je les ai toujours utilisées sans guillemets, mais je ferais écho à l'utilisation de règles strictes et de mises en garde, car elles détectent la plupart des erreurs courantes.