à Perl, lequel d'entre eux est le style "meilleur"? Dans tous les cas, sont-ils des fonctionnalités identiques?
7 Réponses :
Ils sont fonctionnellement identiques, c'est-à-dire jusqu'à ce que votre clé ait un espace ou un autre caractère non alphanumérique. Ensuite, vous devez utiliser l'approche citée.
Je préfère ne pas citer et utiliser des noms contenant alpha_num et le soulignement. Qui me permet de sortir de ne pas citer la plupart du temps.
Ils ne sont pas fonctionnellement identiques. Dans certains cas, vous obtenez le même résultat, mais pas pour la même raison.
La question était de savoir si $ hachage {"string"} est identique à $ hash {string}, ce qui est.
Le dernier format, $ hash {string} est plus concis, mais cela ne fonctionne que pour alphanumériques et soulignes.
de Perldata Perldoc:
En fait, un identifiant dans de telles curlies est forcé d'être une chaîne, tout comme tout identifiant simple dans un indice de hachage. Ni besoin d'une citation. Notre exemple précédent,
$ jours {'févr'} code> peut être écrit comme$ jours {février} code> et les devis seront supposés automatiquement. Mais tout ce qui est plus compliqué dans l'indice sera interprété comme une expression. Cela signifie par exemple queVersion $ {2.0} ++ code> est équivalent àVersion $ {2} ++ code>, pas sur$ version {'2.0'} + + code> p> blockQuote>donc oui fondamentalement identique. Toutefois méfiez-vous de GOTCHAS: P>
$VAR1 = { 'is_sub' => 'Nope', 'Yep!' => 'it is_sub!!' };
Votre exemple concernant Version $ {2.0} vs. code> Version $ {'2.0'} est déroutant pour moi en considérant: perl -e '$ foo {' 2.0 '} = 1; Imprimer $ foo {'2'} ++, $ foo {2} ++, $ foo {2.0} ++, $ foo {1 + 1} ++, "\ n"; ' la valeur dans Les accolades sont évaluées dans un scalaire et ce scalaire est utilisé comme clé. Je dois donc supposer que vous n'avez pas testé votre exemple ni que je manque quelque chose de subtil dans ce que vous essayez de dire. (Pour moi, il imprime 1234 )
Malheureusement, votre exemple est incorrect. En fait, je suis surpris que cela a même analysé OK. Vous utilisez des guillemets simples sur la -E et dans l'indice de hachage. Quoi qu'il en soit, si vous vérifiez vos valeurs de hachage $ FOO après les paramètres, vous obtenez {'2.0' => 1, '2' => 4} ... Quelle est la réponse que vous voudriez voir
Vous pouvez également écrire + fonction au lieu de fonction ().
Plus spécifique de lien: perdoc.perl.org/perldata.html#scalar-value- Constructeurs
Hors pédantique, je cite toujours mes références de chaîne dans un hachage. Il sert à faire en sorte que je ne vais pas avoir un gotcha [1].
[1] Je suis assez conservateur dans mon codage Perl.
+1 Parce que c'est un argument légitime, même si j'ai tendance à être en désaccord.
Êtes-vous en désaccord qu'il évite de certains gotchas? Ou pas d'accord sur des terrains de style? Je suis curieux.
Qu'est-ce que Gotchas ne cite-t-il toujours toujours éviter?
Et si vous avez un sous-baz () {retour 1}? Je n'ai aucune idée de ce que foo {baz} ferait. Je soupçonne que Baz est interpolée dans une chaîne, mais, alors, je ne suis pas sûr. Je sais ce que foo {"baz"} fait, et je sais ce que foo {baz ()} fait.
$ foo {baz} signifie toujours $ foo {baz}. Il n'y a pas vraiment de gotcha. Je dirais que c'est un gotcha si $ foo {baz} signifiait parfois autre chose, mais ça ne le fait pas.
Le formulaire sans guillemets est préféré par la plupart, car il est plus concis et non recutilisé, tant que la clé de hachage est limitée à l'alphanumérique et au soulignement. En outre, la plupart de tout éditeur de support de Syntaxe Perl sait comment les mettre en évidence comme des chaînes malgré eux ne pas être dans les devis.
Il convient de noter que vous pouvez obtenir ce comportement non seulement lorsque vous utilisez des clés hachées, mais lorsque vous définissez des arguments de hachage. , ou même lorsque vous définissez des listes lorsque vous utilisez => code>. Cela peut aider à distinguer visuellement vos clés de vos valeurs dans les deux autres cas. Exemples: P> # Hash construction
my %hash = (
key1 => "val1",
key2 => "val2"
);
# Subroutine arguments
some_function( arg1 => "val1", arg2 => $val2);
sub some_function { my %args = @_; }; # arguments are pulled in as a hash
# List construction (of course, not sure why you'd do this...)
my @list = (Foo => "bar");
print @list; # prints Foobar
Moins d'erreur sujette? J'ai vu plus d'erreurs de personnes n'utilisant pas de citations que de les utiliser. Voir la réponse de Dragtun pour quelques exemples.
@brian: Oui, les deux exemples donnés sont bons, mais pas exactement obscur. Une période est en dehors de l'alphanum Set Alphanum + Souligne, il est donc facile à attraper. Je fais aussi l'habitude d'utiliser personnellement de toujours utiliser des parens avec des méthodes définies par l'utilisateur, de sorte que le deuxième formulaire ne me donne pas non plus. Cependant, je m'incline à votre expérience supérieure et j'ai supprimé cette phrase de ma réponse.
Éviter les guillemets est plus idiomatique.
EDIT Pour ajouter: P>
Ce n'est pas la solution à la lisibilité absolue. Considérons ici l'incohérence ici: P>
$hash{foo} = 1;
$hash{bar} = 2;
$hash{+function} = 3; # aha, this looks different... because it is
# ==> { foo => 1, bar => 2, 'OH HAI' => 3 }
Vous devez toujours $ hash {"string"} sauf si vous voulez $ hash {string} . .
À Perl, les règles de style de rupture sont un bon style!
La première version fonctionne mieux avec le code collé sur le débordement de la pile.
Pourquoi est-ce que tu t'en préoccupes? Vraiment. Il doit sûrement y avoir de meilleures choses à se soucier de votre code. Je me fiche de savoir quelles personnes utilisent aussi longtemps que leurs affaires fonctionnent.
Je suis d'accord avec Brian ici. Pourquoi les soins? Et pourquoi prendre soin de poser une question si elle a été posée auparavant? Stackoverflow.com/questions/401556/...
@brian & Manni - Quelqu'un apprenant simplement Perl peut être terriblement confondu par tous les styles là-bas et Jessica peut être une telle personne. Elle cherche peut-être des «meilleures pratiques» pendant qu'elle apprend la langue. S'ils sont exactement identiques dans toutes les circonstances qui seraient bien à savoir. Depuis qu'ils ne le sont pas et qu'il y a bien beaucoup de "caché" gotchas, c'est encore plus important à savoir. La couper du moule, va-t-il?
Je ne peux pas parler à Brian, mais je la coupe tout le mou du monde. Parfois, "Ne t'inquiète pas" peut être une bonne réponse.