On va pas utiliser un opérateur de concaténation à chaque fois qu'on se trimballe une variable à tripoter dans une string. C'est illisible et impossible à maintenir, surtout si on est en train de construire une requête SQL dynamique où les champs de type textuel doivent être entre ' à cause de la syntaxe SQL.
C'est bien vrai, mais je rajouterais juste une chose, dés que l'on peux avoir le moindre doute sur la lecture, il faut utiliser la concatenation, exemple
echo "lalala $toto_truc lalal";
Si l'on à affaire a $toto, il sera preferable pour la relecture d'ecrire
echo "lalalal".$toto."_truc lalal";
Si PHP remplace les variables par leur valeur dans une string entre doubles quotes, c'est pas fait pour les chiens.
Heureusement car sinon ca n'aurais que peux d'interet, le pourcentage de race canine parmit les codeurs php est bien mince.
Petit ajoute concernant les simples et doubles quotes. Entre simple quote, il n'y a aucun remplacement d'effectué par PHP, donc dans la mesure du possible, il est plus simple d'utiliser les simples quotes surtout quand l'on fait des regex, exemple
le masque ^ le $ est comme le /, un symbole. $
Tout d'abort, il faut proteger les caracteres speciaux de la regex:
^ le $ est comme le , un symbole. $
Puis les caracteres speciaux de php entre doubles quotes.
"^ le $ est comme le \, un symbole. $"
Alors qu'avec simples suotes
'^ le $ est comme le , un symbole. $'
Plus lisible, non ?
-- Guillaume.
John GALLET wrote:
On va pas utiliser un opérateur de concaténation à chaque fois qu'on se
trimballe une variable à tripoter dans une string. C'est illisible et
impossible à maintenir, surtout si on est en train de construire une requête
SQL dynamique où les champs de type textuel doivent être entre ' à cause de
la syntaxe SQL.
C'est bien vrai, mais je rajouterais juste une chose, dés que l'on peux
avoir le moindre doute sur la lecture, il faut utiliser la
concatenation, exemple
echo "lalala $toto_truc lalal";
Si l'on à affaire a $toto, il sera preferable pour la relecture d'ecrire
echo "lalalal".$toto."_truc lalal";
Si PHP remplace les variables par leur valeur dans une string entre doubles
quotes, c'est pas fait pour les chiens.
Heureusement car sinon ca n'aurais que peux d'interet, le pourcentage de
race canine parmit les codeurs php est bien mince.
Petit ajoute concernant les simples et doubles quotes. Entre simple
quote, il n'y a aucun remplacement d'effectué par PHP, donc dans la
mesure du possible, il est plus simple d'utiliser les simples quotes
surtout quand l'on fait des regex, exemple
le masque ^ le $ est comme le /, un symbole. $
Tout d'abort, il faut proteger les caracteres speciaux de la regex:
^ le $ est comme le \, un symbole. $
Puis les caracteres speciaux de php entre doubles quotes.
On va pas utiliser un opérateur de concaténation à chaque fois qu'on se trimballe une variable à tripoter dans une string. C'est illisible et impossible à maintenir, surtout si on est en train de construire une requête SQL dynamique où les champs de type textuel doivent être entre ' à cause de la syntaxe SQL.
C'est bien vrai, mais je rajouterais juste une chose, dés que l'on peux avoir le moindre doute sur la lecture, il faut utiliser la concatenation, exemple
echo "lalala $toto_truc lalal";
Si l'on à affaire a $toto, il sera preferable pour la relecture d'ecrire
echo "lalalal".$toto."_truc lalal";
Si PHP remplace les variables par leur valeur dans une string entre doubles quotes, c'est pas fait pour les chiens.
Heureusement car sinon ca n'aurais que peux d'interet, le pourcentage de race canine parmit les codeurs php est bien mince.
Petit ajoute concernant les simples et doubles quotes. Entre simple quote, il n'y a aucun remplacement d'effectué par PHP, donc dans la mesure du possible, il est plus simple d'utiliser les simples quotes surtout quand l'on fait des regex, exemple
le masque ^ le $ est comme le /, un symbole. $
Tout d'abort, il faut proteger les caracteres speciaux de la regex:
^ le $ est comme le , un symbole. $
Puis les caracteres speciaux de php entre doubles quotes.
"^ le $ est comme le \, un symbole. $"
Alors qu'avec simples suotes
'^ le $ est comme le , un symbole. $'
Plus lisible, non ?
-- Guillaume.
Guillaume Bouchard
Yvon Thoraval wrote:
$tab_types_vins{'Rosé'} et $tab_types_vins['Rosé'] du manière générale entre crochets [] et accolades {} ???
Oui et non.
La syntaxe {} est utilisée pour les chaines de caracteres et la syntaxe [] pour les tableau, question de convention, ne pas changer :)
De plus je pense qu'il peux y avoir des effets etrange avec l'utilisation de [] sur une chaine et inversement.
-- Guillaume.
Yvon Thoraval wrote:
$tab_types_vins{'Rosé'} et $tab_types_vins['Rosé']
du manière générale entre crochets [] et accolades {} ???
Oui et non.
La syntaxe {} est utilisée pour les chaines de caracteres et la syntaxe
[] pour les tableau, question de convention, ne pas changer :)
De plus je pense qu'il peux y avoir des effets etrange avec
l'utilisation de [] sur une chaine et inversement.
$tab_types_vins{'Rosé'} et $tab_types_vins['Rosé'] du manière générale entre crochets [] et accolades {} ???
Oui et non.
La syntaxe {} est utilisée pour les chaines de caracteres et la syntaxe [] pour les tableau, question de convention, ne pas changer :)
De plus je pense qu'il peux y avoir des effets etrange avec l'utilisation de [] sur une chaine et inversement.
-- Guillaume.
Bobe
John GALLET déclarait le 22/08/2003 17:00:
$test = "bonjour $_POST[nom]";
Non non et non : un tableau associatif en php doit avoir le nom de sa clef entre quotes, c'est indiqué texto dans la manuel avec deux écrans d'explications fumeuses quand au pourquoi du comment de la raison.
Il retire ce qu'il a dit et donc Guillaume tu as raison dans le cas où on est déjà entre doubles quotes. http://fr.php.net/manual/en/language.types.array.php
Note: To reiterate, inside a double-quoted string, it's valid to not surround array indexes with quotes so "$foo[bar]" is valid.
Comme quoi s'enfiler les deux pages de blabla de temps à autres c'est pas si mal que ça.
a++ JG
On en apprend tous les jours. Toutes mes excuses Guillaume :/
-- Bobe (Aurélien Maille)
John GALLET déclarait le 22/08/2003 17:00:
$test = "bonjour $_POST[nom]";
Non non et non : un tableau associatif en php doit avoir le nom de sa clef
entre quotes, c'est indiqué texto dans la manuel avec deux écrans
d'explications fumeuses quand au pourquoi du comment de la raison.
Il retire ce qu'il a dit et donc Guillaume tu as raison dans le cas où on
est déjà entre doubles quotes.
http://fr.php.net/manual/en/language.types.array.php
Note: To reiterate, inside a double-quoted string, it's valid to not
surround array indexes with quotes so "$foo[bar]" is valid.
Comme quoi s'enfiler les deux pages de blabla de temps à autres c'est pas si
mal que ça.
a++
JG
On en apprend tous les jours.
Toutes mes excuses Guillaume :/
Non non et non : un tableau associatif en php doit avoir le nom de sa clef entre quotes, c'est indiqué texto dans la manuel avec deux écrans d'explications fumeuses quand au pourquoi du comment de la raison.
Il retire ce qu'il a dit et donc Guillaume tu as raison dans le cas où on est déjà entre doubles quotes. http://fr.php.net/manual/en/language.types.array.php
Note: To reiterate, inside a double-quoted string, it's valid to not surround array indexes with quotes so "$foo[bar]" is valid.
Comme quoi s'enfiler les deux pages de blabla de temps à autres c'est pas si mal que ça.
a++ JG
On en apprend tous les jours. Toutes mes excuses Guillaume :/
-- Bobe (Aurélien Maille)
Guillaume Bouchard
Yvon Thoraval wrote:
Guillaume Bouchard wrote:
La syntaxe {} est utilisée pour les chaines de caracteres et la syntaxe [] pour les tableau, question de convention, ne pas changer :)
hum, donc $_POST['nom'] serait une exception ?
Eu non, $_POST est un tableau... donc []...
-- Guillaume.
Yvon Thoraval wrote:
Guillaume Bouchard <gobpower@free.fr> wrote:
La syntaxe {} est utilisée pour les chaines de caracteres et la syntaxe
[] pour les tableau, question de convention, ne pas changer :)
La syntaxe {} est utilisée pour les chaines de caracteres et la syntaxe
[] pour les tableau, question de convention, ne pas changer :) j'avais mal compris je croyais que tu voulais dire :
{} pour l'indexation des tableaux avec une chaine de caractères [] pour l'indexation des tableaux avec un nombre -- Yvon
John GALLET
cité juste plus haut càd qd $toto est attaché à _truc sur php 4.3.2 me donne une erreur : Notice: Undefined varaible: toto_truc in ... line13...
Tout à fait normal. En dehors de chaînes entre ' le parseur considère tout ce qui commence par $ comme une variable. Ensuite il va s'arrêter au premier caractère interdit dans une variable (espace par exemple). Mais _ est autorisé.
Donc dans un cas comme <3f460fe1$0$253$ (thread appelé "include" commencé le 19/08) on peut effectivement rester dubitatif sur la syntaxe "$ville/connection/alpha.php" mais de là à affirmer froidement "une variable n'a rien à faire dans une chaine de caractères" faut arrêter la moquette.
C'est toujours pareil, il faut que ce que l'on fait soit lisible par une personne de l'extérieur. Il y a beaucoup de plus de problèmes de maintenance de code liés à un manque de commentaires et une mauvaise modularisation en fonctions/objets (bref en code réutilisable et pas en @#! de copiés collés) que de problèmes de lisibilité à cause de variables dans des strings. C'est exactement comme les braves gens qui passent 10 minutes à choisir entre un CHAR et un VARCHAR pour savoir combien de cycles CPU ils vont gagner. Quand ils n'auront plus que ça à optimiser sur les perfs de leur application, on en reparlera. Et bien quand il ne restera que les variables dans ou hors des strings à optimiser en lisibilité du code, on en reparlera aussi.
Et puis si vous trouvez que "...WHERE col3='".$var1."' AND col4='".$var2."' "; c'est facile à écrire, moi pas, si j'ai plus de 3 colonnes je fais une parse error à tous les coups, pas photo là dessus (et faites le en telnet/ssh sous vi en noir et blanc qu'on voit si vous allez faire mieux).
a++ JG
cité juste plus haut càd qd $toto est attaché à _truc sur php 4.3.2 me
donne une erreur :
Notice: Undefined varaible: toto_truc in ... line13...
Tout à fait normal. En dehors de chaînes entre ' le parseur considère tout
ce qui commence par $ comme une variable. Ensuite il va s'arrêter au premier
caractère interdit dans une variable (espace par exemple). Mais _ est
autorisé.
Donc dans un cas comme <3f460fe1$0$253$626a54ce@news.free.fr> (thread appelé
"include" commencé le 19/08) on peut effectivement rester dubitatif sur la
syntaxe "$ville/connection/alpha.php" mais de là à affirmer froidement "une
variable n'a rien à faire dans une chaine de caractères" faut arrêter la
moquette.
C'est toujours pareil, il faut que ce que l'on fait soit lisible par une
personne de l'extérieur. Il y a beaucoup de plus de problèmes de maintenance
de code liés à un manque de commentaires et une mauvaise modularisation en
fonctions/objets (bref en code réutilisable et pas en @#! de copiés collés)
que de problèmes de lisibilité à cause de variables dans des strings. C'est
exactement comme les braves gens qui passent 10 minutes à choisir entre un
CHAR et un VARCHAR pour savoir combien de cycles CPU ils vont gagner. Quand
ils n'auront plus que ça à optimiser sur les perfs de leur application, on
en reparlera. Et bien quand il ne restera que les variables dans ou hors des
strings à optimiser en lisibilité du code, on en reparlera aussi.
Et puis si vous trouvez que "...WHERE col3='".$var1."' AND col4='".$var2."'
"; c'est facile à écrire, moi pas, si j'ai plus de 3 colonnes je fais une
parse error à tous les coups, pas photo là dessus (et faites le en
telnet/ssh sous vi en noir et blanc qu'on voit si vous allez faire mieux).
cité juste plus haut càd qd $toto est attaché à _truc sur php 4.3.2 me donne une erreur : Notice: Undefined varaible: toto_truc in ... line13...
Tout à fait normal. En dehors de chaînes entre ' le parseur considère tout ce qui commence par $ comme une variable. Ensuite il va s'arrêter au premier caractère interdit dans une variable (espace par exemple). Mais _ est autorisé.
Donc dans un cas comme <3f460fe1$0$253$ (thread appelé "include" commencé le 19/08) on peut effectivement rester dubitatif sur la syntaxe "$ville/connection/alpha.php" mais de là à affirmer froidement "une variable n'a rien à faire dans une chaine de caractères" faut arrêter la moquette.
C'est toujours pareil, il faut que ce que l'on fait soit lisible par une personne de l'extérieur. Il y a beaucoup de plus de problèmes de maintenance de code liés à un manque de commentaires et une mauvaise modularisation en fonctions/objets (bref en code réutilisable et pas en @#! de copiés collés) que de problèmes de lisibilité à cause de variables dans des strings. C'est exactement comme les braves gens qui passent 10 minutes à choisir entre un CHAR et un VARCHAR pour savoir combien de cycles CPU ils vont gagner. Quand ils n'auront plus que ça à optimiser sur les perfs de leur application, on en reparlera. Et bien quand il ne restera que les variables dans ou hors des strings à optimiser en lisibilité du code, on en reparlera aussi.
Et puis si vous trouvez que "...WHERE col3='".$var1."' AND col4='".$var2."' "; c'est facile à écrire, moi pas, si j'ai plus de 3 colonnes je fais une parse error à tous les coups, pas photo là dessus (et faites le en telnet/ssh sous vi en noir et blanc qu'on voit si vous allez faire mieux).
a++ JG
pjvouette
"Ben}{ur" a écrit dans le message news:
Le Fri, 22 Aug 2003 16:37:11 +0200, John GALLET a ecrit:
Au contraire... je n'ai jamais utilisé une variable dans une chaine. Je trouve cela vraiment tres dangereux et, a ma connaissance, c'est le seul language qui le permet (malheureusement)
Euh, les divers printf ont disparu de la librairie standard du C ?
La principale différence entre : $titi = " la $taquetaquetic du $gendarme" ; et (à la PHP) : $titi = sprintf("la %s du %s", $taquetaquetic, $gendarme) ; c'est que dans le premier cas les arguments sont nommés.
pierre-jean
"Ben}{ur" <benoitdotbouillard@wanadoo.fr> a écrit dans le message news:
pan.2003.08.22.23.09.43.617395.12366@wanadoo.fr...
Le Fri, 22 Aug 2003 16:37:11 +0200, John GALLET a ecrit:
Au contraire... je n'ai jamais utilisé une variable dans une chaine. Je
trouve cela vraiment tres dangereux et, a ma connaissance, c'est le seul
language qui le permet (malheureusement)
Euh, les divers printf ont disparu de la librairie standard du C ?
La principale différence entre : $titi = " la $taquetaquetic du $gendarme" ;
et (à la PHP) : $titi = sprintf("la %s du %s", $taquetaquetic, $gendarme) ;
c'est que dans le premier cas les arguments sont nommés.
Le Fri, 22 Aug 2003 16:37:11 +0200, John GALLET a ecrit:
Au contraire... je n'ai jamais utilisé une variable dans une chaine. Je trouve cela vraiment tres dangereux et, a ma connaissance, c'est le seul language qui le permet (malheureusement)
Euh, les divers printf ont disparu de la librairie standard du C ?
La principale différence entre : $titi = " la $taquetaquetic du $gendarme" ; et (à la PHP) : $titi = sprintf("la %s du %s", $taquetaquetic, $gendarme) ; c'est que dans le premier cas les arguments sont nommés.
pierre-jean
yvon.thoravallist
John GALLET wrote:
Tout à fait normal. En dehors de chaînes entre ' le parseur considère tout ce qui commence par $ comme une variable. Ensuite il va s'arrêter au premier caractère interdit dans une variable (espace par exemple). Mais _ est autorisé. ben oui, je ne vois d'ailleurs comment un parseur pourraiy faire
autrement, à moins que _ soit un caractère interdit dans les vars, mon commentaire était caustique...
Donc dans un cas comme <3f460fe1$0$253$ (thread appelé "include" commencé le 19/08) on peut effectivement rester dubitatif sur la syntaxe "$ville/connection/alpha.php" mais de là à affirmer froidement "une variable n'a rien à faire dans une chaine de caractères" faut arrêter la moquette.
j'utilise régulièrement un "/cave/{$page}" qui marche très bien mais ce n'est pas toutàfait la même situation (fin de chaîne). Il me semble que le / est aussi une valeur interdite dans un nom de variable non ?
C'est toujours pareil, il faut que ce que l'on fait soit lisible par une personne de l'extérieur. [...]
Et puis si vous trouvez que "...WHERE col3='".$var1."' AND col4='".$var2."' "; c'est facile à écrire, moi pas, si j'ai plus de 3 colonnes je fais une parse error à tous les coups, pas photo là dessus (et faites le en telnet/ssh sous vi en noir et blanc qu'on voit si vous allez faire mieux).
c'est vrai que c'est fatiguant surtout que, sur mon clavier mac, pour avoir le . il faut faire shift ; ... perso pour la lisibilité d'un prog je trouve effectivement qu'une prog. style OOP est nettement plus lisible si l'on prend bien le soin de choisir des noms de vars et de fonctions qui font sens. -- Yvon
John GALLET <john.gallet@wanadoo.fr> wrote:
Tout à fait normal. En dehors de chaînes entre ' le parseur considère tout
ce qui commence par $ comme une variable. Ensuite il va s'arrêter au premier
caractère interdit dans une variable (espace par exemple). Mais _ est
autorisé.
ben oui, je ne vois d'ailleurs comment un parseur pourraiy faire
autrement, à moins que _ soit un caractère interdit dans les vars, mon
commentaire était caustique...
Donc dans un cas comme <3f460fe1$0$253$626a54ce@news.free.fr> (thread appelé
"include" commencé le 19/08) on peut effectivement rester dubitatif sur la
syntaxe "$ville/connection/alpha.php" mais de là à affirmer froidement "une
variable n'a rien à faire dans une chaine de caractères" faut arrêter la
moquette.
j'utilise régulièrement un "/cave/{$page}" qui marche très bien mais ce
n'est pas toutàfait la même situation (fin de chaîne). Il me semble que
le / est aussi une valeur interdite dans un nom de variable non ?
C'est toujours pareil, il faut que ce que l'on fait soit lisible par une
personne de l'extérieur.
[...]
Et puis si vous trouvez que "...WHERE col3='".$var1."' AND col4='".$var2."'
"; c'est facile à écrire, moi pas, si j'ai plus de 3 colonnes je fais une
parse error à tous les coups, pas photo là dessus (et faites le en
telnet/ssh sous vi en noir et blanc qu'on voit si vous allez faire mieux).
c'est vrai que c'est fatiguant surtout que, sur mon clavier mac, pour
avoir le . il faut faire shift ; ...
perso pour la lisibilité d'un prog je trouve effectivement qu'une prog.
style OOP est nettement plus lisible si l'on prend bien le soin de
choisir des noms de vars et de fonctions qui font sens.
--
Yvon
Tout à fait normal. En dehors de chaînes entre ' le parseur considère tout ce qui commence par $ comme une variable. Ensuite il va s'arrêter au premier caractère interdit dans une variable (espace par exemple). Mais _ est autorisé. ben oui, je ne vois d'ailleurs comment un parseur pourraiy faire
autrement, à moins que _ soit un caractère interdit dans les vars, mon commentaire était caustique...
Donc dans un cas comme <3f460fe1$0$253$ (thread appelé "include" commencé le 19/08) on peut effectivement rester dubitatif sur la syntaxe "$ville/connection/alpha.php" mais de là à affirmer froidement "une variable n'a rien à faire dans une chaine de caractères" faut arrêter la moquette.
j'utilise régulièrement un "/cave/{$page}" qui marche très bien mais ce n'est pas toutàfait la même situation (fin de chaîne). Il me semble que le / est aussi une valeur interdite dans un nom de variable non ?
C'est toujours pareil, il faut que ce que l'on fait soit lisible par une personne de l'extérieur. [...]
Et puis si vous trouvez que "...WHERE col3='".$var1."' AND col4='".$var2."' "; c'est facile à écrire, moi pas, si j'ai plus de 3 colonnes je fais une parse error à tous les coups, pas photo là dessus (et faites le en telnet/ssh sous vi en noir et blanc qu'on voit si vous allez faire mieux).
c'est vrai que c'est fatiguant surtout que, sur mon clavier mac, pour avoir le . il faut faire shift ; ... perso pour la lisibilité d'un prog je trouve effectivement qu'une prog. style OOP est nettement plus lisible si l'on prend bien le soin de choisir des noms de vars et de fonctions qui font sens. -- Yvon
yvon.thoravallist
Bobe wrote:
$var = 'bon'; $texte = "Voici un exemple : {$var}jour";
sans les accolades, php considère qu'on "demande" la variable $varjour
