ProgrammationDéveloppeur Backend

Quelles sont les spécificités du travail avec le traitement de la liste des arguments dans les sous-programmes Perl, et comment retourner correctement des valeurs depuis une fonction ?

Réussissez les entretiens avec l'assistant IA Hintsage

Réponse

Dans Perl, les sous-programmes prennent des arguments via une variable spéciale tableau @_, où tous les paramètres transmis sont automatiquement placés. La spécificité de Perl est que les paramètres sont passés par référence dans @_, ce qui signifie que la modification des éléments à l'intérieur de la fonction change leurs valeurs à l'extérieur.

Pour éviter des modifications inattendues des données transmises, il est recommandé de copier les paramètres dans des variables :

sub sum { my ($a, $b) = @_; return $a + $b; }

Les fonctions Perl retournent toujours une liste de valeurs, et le résultat de la fonction est la dernière liste calculée ou une instruction return explicite.

sub minmax { my ($x, $y) = @_; return ($x < $y ? $x : $y, $x > $y ? $x : $y); } my ($min, $max) = minmax(4, 7); # $min = 4; $max = 7

Si vous appelez la fonction dans un contexte scalaire, elle retournera le nombre d'éléments retournés, à moins que le résultat ne soit pas encapsulé dans un scalaire.


Question piège

Comment passer un grand nombre de variables à une fonction Perl sans modifier accidentellement les valeurs des variables d'origine ?

Ils répondent inconsciemment : "Il suffit de copier les arguments dans des variables comme d'habitude !"

Réponse correcte :

Le copiage fonctionne uniquement pour les scalaires. Si vous travaillez avec des tableaux ou des hachages, utilisez des références pour gérer le passage de données explicitement et éviter les copies par référence :

sub modify { my ($arr_ref) = @_; push @$arr_ref, 'new'; # modifie le tableau d'origine } my @data = (1, 2, 3); modify(\@data); # maintenant @data = (1, 2, 3, 'new')

Histoire


Histoire 1

Dans un grand script de traitement de rapports, une fonction interne modifiait les valeurs des éléments d'un tableau transmis depuis le programme principal. En conséquence, après l'exécution de la fonction, les données d'origine étaient corrompues. L'erreur provenait du fait que l'auteur de la fonction ne faisait pas de copies des valeurs d'entrée, pensant que les modifications seraient locales — ce qui est faux pour @_ avec les tableaux.


Histoire 2

Lors de la migration de scripts de Perl 4 (où les variables étaient copiées différemment), l'équipe a rencontré un problème : le passage de hachages imbriqués entraînait une "fuite" inattendue de données entre les appels de sous-programmes — la modification des champs du hachage dans une fonction affectait d'autres parties du code. La raison était une référence au hachage dans la liste @_.


Histoire 3

Un développeur a implémenté une fonction renvoyant un tableau de résultats, mais au point d'appel, il a utilisé un contexte scalaire : $count = func(@params);. Il était attendu que la variable reçoive la valeur du premier élément retourné, mais dans les faits, $count contenait le nombre d'éléments dans la liste, ce qui a conduit à des retards dans les calculs et à de la confusion.