veuillez pardonner cette question de novice, mais je n'ai jamais su, depuis
le temps que je fais du perl, quand est-ce qu'on met des parenthèses de
quand est-ce qu'on ne les met pas? Par exemple, quand j'étais jeune j'ai
appris que la syntaxe de push était push(@toto,$titi) . Mais je me suis
aperçu que push @toto, $titi sans parenthèses marchait aussi bien. Pareil
pour split. En revanche, dans certains cas, si on retire les parenthèses on
a une erreur de syntaxe (je n'ai pas d'exemple sous la main). Y a t il une
règle?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Paul Gaborit
À (at) Sat, 16 Jan 2010 12:56:43 +0100, "Patrice" écrivait (wrote):
veuillez pardonner cette question de novice, mais je n'ai jamais su, depuis le temps que je fais du perl, quand est-ce qu'on met des parenthèses de quand est-ce qu'on ne les met pas? Par exemple, quand j'étais jeune j'ai appris que la syntaxe de push était push(@toto,$titi) . Mais je me suis aperçu que push @toto, $titi sans parenthèses marchait aussi bien. Pareil pour split. En revanche, dans certains cas, si on retire les parenthèses on a une erreur de syntaxe (je n'ai pas d'exemple sous la main). Y a t il une règle?
Les parenthèses des appels de fonctions sont optionnelles si la fonction appelée est déjà déclarée. Ex :
sub retourne { return reverse @_; }
print retourne 1, 2, 3; # affiche 321
Mais elle redeviennent utiles pour fixer la fin d'une liste d'arguments :
print retourne(1, 2), 3; # affiche 213
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
À (at) Sat, 16 Jan 2010 12:56:43 +0100,
"Patrice" <patrice@nospam.fr> écrivait (wrote):
veuillez pardonner cette question de novice, mais je n'ai jamais su,
depuis le temps que je fais du perl, quand est-ce qu'on met des
parenthèses de quand est-ce qu'on ne les met pas? Par exemple, quand
j'étais jeune j'ai appris que la syntaxe de push était
push(@toto,$titi) . Mais je me suis aperçu que push @toto, $titi sans
parenthèses marchait aussi bien. Pareil pour split. En revanche, dans
certains cas, si on retire les parenthèses on a une erreur de syntaxe
(je n'ai pas d'exemple sous la main). Y a t il une règle?
Les parenthèses des appels de fonctions sont optionnelles si la
fonction appelée est déjà déclarée. Ex :
sub retourne {
return reverse @_;
}
print retourne 1, 2, 3; # affiche 321
Mais elle redeviennent utiles pour fixer la fin d'une liste
d'arguments :
print retourne(1, 2), 3; # affiche 213
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
À (at) Sat, 16 Jan 2010 12:56:43 +0100, "Patrice" écrivait (wrote):
veuillez pardonner cette question de novice, mais je n'ai jamais su, depuis le temps que je fais du perl, quand est-ce qu'on met des parenthèses de quand est-ce qu'on ne les met pas? Par exemple, quand j'étais jeune j'ai appris que la syntaxe de push était push(@toto,$titi) . Mais je me suis aperçu que push @toto, $titi sans parenthèses marchait aussi bien. Pareil pour split. En revanche, dans certains cas, si on retire les parenthèses on a une erreur de syntaxe (je n'ai pas d'exemple sous la main). Y a t il une règle?
Les parenthèses des appels de fonctions sont optionnelles si la fonction appelée est déjà déclarée. Ex :
sub retourne { return reverse @_; }
print retourne 1, 2, 3; # affiche 321
Mais elle redeviennent utiles pour fixer la fin d'une liste d'arguments :
print retourne(1, 2), 3; # affiche 213
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
Patrick Texier
Le Sat, 16 Jan 2010 16:27:49 +0100, Paul Gaborit a écrit :
Les parenthèses des appels de fonctions sont optionnelles si la fonction appelée est déjà déclarée. Ex :
sub retourne { return reverse @_; }
print retourne 1, 2, 3; # affiche 321
C'est surtout question de lisibilité : dans cet exemple je les mettrais. -- Patrick Texier
vim:syntax=mail:ai:ts=4:et:twr
Le Sat, 16 Jan 2010 16:27:49 +0100, Paul Gaborit a écrit :
Les parenthèses des appels de fonctions sont optionnelles si la
fonction appelée est déjà déclarée. Ex :
sub retourne {
return reverse @_;
}
print retourne 1, 2, 3; # affiche 321
C'est surtout question de lisibilité : dans cet exemple je les mettrais.
--
Patrick Texier
Le Sat, 16 Jan 2010 16:27:49 +0100, Paul Gaborit a écrit :
Les parenthèses des appels de fonctions sont optionnelles si la fonction appelée est déjà déclarée. Ex :
sub retourne { return reverse @_; }
print retourne 1, 2, 3; # affiche 321
C'est surtout question de lisibilité : dans cet exemple je les mettrais. -- Patrick Texier
vim:syntax=mail:ai:ts=4:et:twr
xavier
Patrick Texier wrote:
C'est surtout question de lisibilité : dans cet exemple je les mettrais.
Pour ma part, pour justement, des questions de lisibilité, je les mets partout où elles ont un sens.
Systématiquement, donc, dans les appels de fonctions. Même les fonctions sans paramètres, j'ai toujours tendance à préférer la notation func() à la notation &func C'est plus cohérent, amha.
Et pour résumer, mon "coding style" est de se rapprocher le plus possible de la syntaxe C/C++ chaque fois que possible. Je ne prétends pas que c'est le meilleur style, mais il faut bien en choisir un, et s'y tenir, sous peine de ne pas pouvoir relire son propre code.
-- XAv Disponible au 01/06/2010 <http://www.xavierhumbert.net/perso/CV2.html>
Patrick Texier <p.texier@alussinan.org> wrote:
C'est surtout question de lisibilité : dans cet exemple je les mettrais.
Pour ma part, pour justement, des questions de lisibilité, je les mets
partout où elles ont un sens.
Systématiquement, donc, dans les appels de fonctions. Même les fonctions
sans paramètres, j'ai toujours tendance à préférer la notation func() à
la notation &func C'est plus cohérent, amha.
Et pour résumer, mon "coding style" est de se rapprocher le plus
possible de la syntaxe C/C++ chaque fois que possible. Je ne prétends
pas que c'est le meilleur style, mais il faut bien en choisir un, et s'y
tenir, sous peine de ne pas pouvoir relire son propre code.
--
XAv
Disponible au 01/06/2010
<http://www.xavierhumbert.net/perso/CV2.html>
C'est surtout question de lisibilité : dans cet exemple je les mettrais.
Pour ma part, pour justement, des questions de lisibilité, je les mets partout où elles ont un sens.
Systématiquement, donc, dans les appels de fonctions. Même les fonctions sans paramètres, j'ai toujours tendance à préférer la notation func() à la notation &func C'est plus cohérent, amha.
Et pour résumer, mon "coding style" est de se rapprocher le plus possible de la syntaxe C/C++ chaque fois que possible. Je ne prétends pas que c'est le meilleur style, mais il faut bien en choisir un, et s'y tenir, sous peine de ne pas pouvoir relire son propre code.
-- XAv Disponible au 01/06/2010 <http://www.xavierhumbert.net/perso/CV2.html>
espie
In article <1jcffpl.5wys1n1rp1vtrN%, Xavier wrote:
Patrick Texier wrote:
C'est surtout question de lisibilité : dans cet exemple je les mettrais.
Pour ma part, pour justement, des questions de lisibilité, je les mets partout où elles ont un sens.
Systématiquement, donc, dans les appels de fonctions. Même les fonctions sans paramètres, j'ai toujours tendance à préférer la notation func() à la notation &func C'est plus cohérent, amha.
Cote coding style, j'ai completement arrete de les mettre pour les appels de methods sans parametre. Et je trouve ca vachement plus lisible,
Par exemple:
my $o = $plist->signature; my $r = $n->compare($o); $state->print("Comparing full signature for ", $plist->pkgname, " "", $o->string, "" vs. "", $n->string,"": ") if $state->verbose >= 3;
In article <1jcffpl.5wys1n1rp1vtrN%xavier@groumpf.org>,
Xavier <xavier@groumpf.org> wrote:
Patrick Texier <p.texier@alussinan.org> wrote:
C'est surtout question de lisibilité : dans cet exemple je les mettrais.
Pour ma part, pour justement, des questions de lisibilité, je les mets
partout où elles ont un sens.
Systématiquement, donc, dans les appels de fonctions. Même les fonctions
sans paramètres, j'ai toujours tendance à préférer la notation func() à
la notation &func C'est plus cohérent, amha.
Cote coding style, j'ai completement arrete de les mettre pour les appels
de methods sans parametre. Et je trouve ca vachement plus lisible,
Par exemple:
my $o = $plist->signature;
my $r = $n->compare($o);
$state->print("Comparing full signature for ",
$plist->pkgname, " "", $o->string, "" vs. "",
$n->string,"": ")
if $state->verbose >= 3;
In article <1jcffpl.5wys1n1rp1vtrN%, Xavier wrote:
Patrick Texier wrote:
C'est surtout question de lisibilité : dans cet exemple je les mettrais.
Pour ma part, pour justement, des questions de lisibilité, je les mets partout où elles ont un sens.
Systématiquement, donc, dans les appels de fonctions. Même les fonctions sans paramètres, j'ai toujours tendance à préférer la notation func() à la notation &func C'est plus cohérent, amha.
Cote coding style, j'ai completement arrete de les mettre pour les appels de methods sans parametre. Et je trouve ca vachement plus lisible,
Par exemple:
my $o = $plist->signature; my $r = $n->compare($o); $state->print("Comparing full signature for ", $plist->pkgname, " "", $o->string, "" vs. "", $n->string,"": ") if $state->verbose >= 3;
Paul Gaborit
À (at) Sat, 16 Jan 2010 18:23:38 +0100, Patrick Texier écrivait (wrote):
Le Sat, 16 Jan 2010 16:27:49 +0100, Paul Gaborit a écrit :
Les parenthèses des appels de fonctions sont optionnelles si la fonction appelée est déjà déclarée. Ex :
sub retourne { return reverse @_; }
print retourne 1, 2, 3; # affiche 321
C'est surtout question de lisibilité : dans cet exemple je les mettrais.
C'est sûr : le fait qu'elles soient optionnelles n'empêche pas de les utiliser.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
À (at) Sat, 16 Jan 2010 18:23:38 +0100,
Patrick Texier <p.texier@alussinan.org> écrivait (wrote):
Le Sat, 16 Jan 2010 16:27:49 +0100, Paul Gaborit a écrit :
Les parenthèses des appels de fonctions sont optionnelles si la
fonction appelée est déjà déclarée. Ex :
sub retourne {
return reverse @_;
}
print retourne 1, 2, 3; # affiche 321
C'est surtout question de lisibilité : dans cet exemple je les mettrais.
C'est sûr : le fait qu'elles soient optionnelles n'empêche pas de les
utiliser.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
À (at) Sat, 16 Jan 2010 18:23:38 +0100, Patrick Texier écrivait (wrote):
Le Sat, 16 Jan 2010 16:27:49 +0100, Paul Gaborit a écrit :
Les parenthèses des appels de fonctions sont optionnelles si la fonction appelée est déjà déclarée. Ex :
sub retourne { return reverse @_; }
print retourne 1, 2, 3; # affiche 321
C'est surtout question de lisibilité : dans cet exemple je les mettrais.
C'est sûr : le fait qu'elles soient optionnelles n'empêche pas de les utiliser.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
Paul Gaborit
À (at) Sat, 16 Jan 2010 19:40:16 +0100, (Xavier) écrivait (wrote):
Patrick Texier wrote:
C'est surtout question de lisibilité : dans cet exemple je les mettrais.
Pour ma part, pour justement, des questions de lisibilité, je les mets partout où elles ont un sens.
Systématiquement, donc, dans les appels de fonctions. Même les fonctions sans paramètres, j'ai toujours tendance à préférer la notation func() à la notation &func C'est plus cohérent, amha.
Si la fonction est déjà déclarée, le choix est entre :
func arg1, arg2, arg3;
et :
func(arg1, arg2, arg3);
Les notations avec un & devant n'ont pas le même sens : avec parenthèses, le & supprime la vérification du prototype. Et sans parenthèse, le & passe @_ comme argument à la fonction appelée.
Pour le style, personnellement, je préfère enlever les parenthèses lorsque c'est possible car, en général, cela augmente la lisibilité. Ex :
push @tab, 1, 2, 3;
plutôt que :
push(@tab, 1, 2, 3);
Un autre exemple :
foreach my $val (reverse sort grep {$_ ne "a"} @tab) { ... }
plutôt que :
foreach my $val (reverse(sort(grep({$_ ne "a"} @tab)))) { ... }
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
À (at) Sat, 16 Jan 2010 19:40:16 +0100,
xavier@groumpf.org (Xavier) écrivait (wrote):
Patrick Texier <p.texier@alussinan.org> wrote:
C'est surtout question de lisibilité : dans cet exemple je les mettrais.
Pour ma part, pour justement, des questions de lisibilité, je les mets
partout où elles ont un sens.
Systématiquement, donc, dans les appels de fonctions. Même les fonctions
sans paramètres, j'ai toujours tendance à préférer la notation func() à
la notation &func C'est plus cohérent, amha.
Si la fonction est déjà déclarée, le choix est entre :
func arg1, arg2, arg3;
et :
func(arg1, arg2, arg3);
Les notations avec un & devant n'ont pas le même sens : avec
parenthèses, le & supprime la vérification du prototype. Et sans
parenthèse, le & passe @_ comme argument à la fonction appelée.
Pour le style, personnellement, je préfère enlever les parenthèses
lorsque c'est possible car, en général, cela augmente la
lisibilité. Ex :
push @tab, 1, 2, 3;
plutôt que :
push(@tab, 1, 2, 3);
Un autre exemple :
foreach my $val (reverse sort grep {$_ ne "a"} @tab) {
...
}
plutôt que :
foreach my $val (reverse(sort(grep({$_ ne "a"} @tab)))) {
...
}
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
À (at) Sat, 16 Jan 2010 19:40:16 +0100, (Xavier) écrivait (wrote):
Patrick Texier wrote:
C'est surtout question de lisibilité : dans cet exemple je les mettrais.
Pour ma part, pour justement, des questions de lisibilité, je les mets partout où elles ont un sens.
Systématiquement, donc, dans les appels de fonctions. Même les fonctions sans paramètres, j'ai toujours tendance à préférer la notation func() à la notation &func C'est plus cohérent, amha.
Si la fonction est déjà déclarée, le choix est entre :
func arg1, arg2, arg3;
et :
func(arg1, arg2, arg3);
Les notations avec un & devant n'ont pas le même sens : avec parenthèses, le & supprime la vérification du prototype. Et sans parenthèse, le & passe @_ comme argument à la fonction appelée.
Pour le style, personnellement, je préfère enlever les parenthèses lorsque c'est possible car, en général, cela augmente la lisibilité. Ex :
push @tab, 1, 2, 3;
plutôt que :
push(@tab, 1, 2, 3);
Un autre exemple :
foreach my $val (reverse sort grep {$_ ne "a"} @tab) { ... }
plutôt que :
foreach my $val (reverse(sort(grep({$_ ne "a"} @tab)))) { ... }
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
