Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

j'apprends php 1

41 réponses
Avatar
Olivier Masson
Bonjour,

Dans le cadre de ma décision "j'apprends à coder proprement et
efficacement", j'ai 2.5 questions à vous poser (ça ne fait que commencer
:)).

Tout d'abord, pourquoi ne peut-on pas faire :
$a = (explode("?",$string))[0];
puisque explode renvoie un array ?

Ensuite, pourquoi ceci ne fonctionne pas :
array_flip($a);
ni même :
array_flip(&$a);
On est donc forcé d'écrire :
$a = array_flip($a);
?

La demi-question : Est-il (vraiment) utile de faire un unset dès que
l'on a plus besoin d'une variable si cette variable ne contient pas des
tonnes de données ?

Petite anecdote : hier en cherchant si qq un avait déjà codé ce que je
voulais, je suis tombé sur une solution.
Elle est publiée sur le site d'une agence web. Bon.
Cette solution fait 50 lignes, qui ressemblent à s'y méprendre à du
visualbasic codé par un enfant de 10ans.
Voyant ça, j'ai cherché de mon côté pour, au final, arriver à un
meilleur résultat en... 5 lignes (et 15 minutes de recherche dans le doc
php) !
Jusque là, vous me direz, c'est commun dans le monde du web. Sauf que
cette agence à créer son CMS en PHP :) (et là, c'est le drame).

Je ne veux pas devenir comme ça ! Alors je pose des questions :)
Et comme d'hab, c'est sympa de votre part d'y répondre.

10 réponses

1 2 3 4 5
Avatar
Mickaël Wolff
Olivier Masson a écrit :

Tout d'abord, pourquoi ne peut-on pas faire :
$a = (explode("?",$string))[0];
puisque explode renvoie un array ?



C'est une limitation de la grammaire de PHP. Certainement des
implémentations ont été proposées, mais soit les performances, soit les
effets de bord ne permirent pas son intégration.

Ensuite, pourquoi ceci ne fonctionne pas :
array_flip($a);
ni même :
array_flip(&$a);
On est donc forcé d'écrire :
$a = array_flip($a);
?



Là tu touche un point sensible du microcosme PHP. La documentation
dit qu'on renvoie le tableau modifié, donc c'est normal.
A noter qu'il n'y a pas de logique globale dans le nom des fonctions,
l'ordre des arguments, ou encore de la manière dont sont traités les
arguments par les fonctions natives.

La demi-question : Est-il (vraiment) utile de faire un unset dès que
l'on a plus besoin d'une variable si cette variable ne contient pas des
tonnes de données ?



Très franchement, on s'en fout. Hormis pour les données volumineuse,
j'ai tendance à ne pas m'en soucier. PHP est censé gérer la mémoire.

Petite anecdote : hier en cherchant si qq un avait déjà codé ce que je
voulais, je suis tombé sur une solution.
Elle est publiée sur le site d'une agence web. Bon.
Cette solution fait 50 lignes, qui ressemblent à s'y méprendre à du
visualbasic codé par un enfant de 10ans.



Oui, du PHP :p

Voyant ça, j'ai cherché de mon côté pour, au final, arriver à un
meilleur résultat en... 5 lignes (et 15 minutes de recherche dans le doc
php) !



Ca dépend de ce que tu entends par « meilleur », dans quel contexte.
La concision n'est pas forcément ce qu'il y a de plus intelligent.


--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Avatar
Bruno Desthuilliers
Olivier Masson a écrit :
Bonjour,

Dans le cadre de ma décision "j'apprends à coder proprement et
efficacement", j'ai 2.5 questions à vous poser (ça ne fait que commencer
:)).

Tout d'abord, pourquoi ne peut-on pas faire :
$a = (explode("?",$string))[0];
puisque explode renvoie un array ?



Parce que PHP est codé avec les pieds !-)

Certaines opérations ne peuvent être appliquées qu'à des variables, pas
à des expressions. Bref, c'est une limitation de l'interpréteur PHP.

Ensuite, pourquoi ceci ne fonctionne pas :
array_flip($a);
ni même :
array_flip(&$a);
On est donc forcé d'écrire :
$a = array_flip($a);
?



parce que array_flip est une "vraie" fonction - et fonctionne donc sans
effet de bord. Ca, à mon sens, c'est plutôt une BonneChose. D'autant que
je ne suis pas sûr qu'il soit possible d'implémenter efficacement ce
type d'opération réellement "en place" (c'est à dire sans créer au moins
temporairement un second tableau), contrairement à, par exemple, un tri
ou un reverse.

<plug>
Tiens au fait, quelqu'un sait comment sont implémentés les tableaux de
PHP ? (ok, je pourrais regarder dans le source, mais là j'ai un peu la
flemme).
</plug>

La demi-question : Est-il (vraiment) utile de faire un unset dès que
l'on a plus besoin d'une variable si cette variable ne contient pas des
tonnes de données ?



Dans l'absolu, non. Accessoirement, pour les variables locales, elles
sont (théoriquement...) libérées automatiquement à la sortie de la
fonction.

Petite anecdote : hier en cherchant si qq un avait déjà codé ce que je
voulais, je suis tombé sur une solution.
Elle est publiée sur le site d'une agence web. Bon.
Cette solution fait 50 lignes, qui ressemblent à s'y méprendre à du
visualbasic codé par un enfant de 10ans.



C'est très courant dans le code produit par des agences web (et je sais
de quoi je parles, mouarf...).

Voyant ça, j'ai cherché de mon côté pour, au final, arriver à un
meilleur résultat en... 5 lignes (et 15 minutes de recherche dans le doc
php) !
Jusque là, vous me direz, c'est commun dans le monde du web.



Pas seulement. Si tu savais les horreurs que j'ai vu dans des applis de
gestion...

Sauf que
cette agence à créer son CMS en PHP :) (et là, c'est le drame).



Rien que de très ordinaire, hélas.

Je ne veux pas devenir comme ça ! Alors je pose des questions :)



méfie toi des réponses !-||
Avatar
Olivier Masson
Mickaël Wolff a écrit :


Là tu touche un point sensible du microcosme PHP. La documentation
dit qu'on renvoie le tableau modifié, donc c'est normal.
A noter qu'il n'y a pas de logique globale dans le nom des fonctions,
l'ordre des arguments, ou encore de la manière dont sont traités les
arguments par les fonctions natives.



Pourquoi, dans d'autres langages oui ?
Je ne comprends pas ce que ça (n')implique (pas).

Petite anecdote : hier en cherchant si qq un avait déjà codé ce que je
voulais, je suis tombé sur une solution.
Elle est publiée sur le site d'une agence web. Bon.
Cette solution fait 50 lignes, qui ressemblent à s'y méprendre à du
visualbasic codé par un enfant de 10ans.



Oui, du PHP :p



Quand je regarde certains CMS, je trouve ça très propre *visuellement*
(il faut bien comprendre que l'esthétique du code est également un
analyse rapide de la manière de coder ; je dois être synesthésique :)).
Il y a peut-être de grosses erreurs de conception que je ne vois et ne
verrai jamais, mais elles sont à un tout autre niveau que
l'enchevêtrement de if, elseif et foreach sans aucune fonction
spécifique que je vois souvent, et notamment dans le code dont je parle
ci-après.


Ca dépend de ce que tu entends par « meilleur », dans quel contexte.
La concision n'est pas forcément ce qu'il y a de plus intelligent.





Dans ce cas, quelque soit le contexte, je peux vous te l'assurer (bon
j'étais méchant, hors commentaires et accolade, ils sont sur ~30 lignes) !
Avatar
Christophe Bachmann
Olivier Masson a écrit :
Mickaël Wolff a écrit :

A noter qu'il n'y a pas de logique globale dans le nom des fonctions,
l'ordre des arguments, ou encore de la manière dont sont traités les
arguments par les fonctions natives.



Pourquoi, dans d'autres langages oui ?
Je ne comprends pas ce que ça (n')implique (pas).



Dans pas mal de langages bien conçus, les fonctions ont des noms conçus
pour être faciles à mémoriser, les arguments sont toujours ordonnés de
la même façon et sont traités de façon identique (par exemple une
fonction de conversion renvoie toujours la valeur passée dans le premier
argument convertie dans le deuxième argument et retourne une valeur
booléenne indiquant la réussite ou non de la conversion).

Ca implique que quand on connaît la philosophie du langage on peut
deviner le nom d'une fonction dont on a besoin, et même l'ordre et le
type de ses arguments sans avoir besoin d'aller vérifier dans la doc en
permanence, et risquer une erreur stupide par ce qu'on a confondu la
syntaxe de deux fonctions proches.
--
Greetings, Salutations,
Guiraud Belissen, Château du Ciel, Drachenwald,
Chris CII, Rennes, France
Avatar
Bruno Desthuilliers
Olivier Masson a écrit :
Mickaël Wolff a écrit :


Là tu touche un point sensible du microcosme PHP. La documentation
dit qu'on renvoie le tableau modifié, donc c'est normal.
A noter qu'il n'y a pas de logique globale dans le nom des fonctions,
l'ordre des arguments, ou encore de la manière dont sont traités les
arguments par les fonctions natives.



Pourquoi, dans d'autres langages oui ?



Disons que, au moins au niveau des fonctions builtins et des
bibliothèques standards, la plupart des autres langages essaient de
rester cohérent dans les conventions de nommage, l'ordre des arguments
pour des fonctionnalités similaires, et le mode d'appel (vraie fonction
ou transformation "en place").

En Python, par exemple, je n'ai que très rarement besoin de consulter la
doc pour vérifier un de ces points. En PHP, et particulièrement pour ce
qui touche aux chaines de caractères et aux tableaux (bref, aux deux
types de données les plus essentiels du langage dans ses applications
pratiques), je dois *systématiquement* lire la doc (et ce après
plusieurs années d'utilisation professionnelle et quotidienne).

Je ne comprends pas ce que ça (n')implique (pas).



Ca implique que je suis nettement plus productif en Python qu'en PHP.

Petite anecdote : hier en cherchant si qq un avait déjà codé ce que
je voulais, je suis tombé sur une solution.
Elle est publiée sur le site d'une agence web. Bon.
Cette solution fait 50 lignes, qui ressemblent à s'y méprendre à du
visualbasic codé par un enfant de 10ans.



Oui, du PHP :p



Quand je regarde certains CMS, je trouve ça très propre *visuellement*
(il faut bien comprendre que l'esthétique du code est également un
analyse rapide de la manière de coder ; je dois être synesthésique :)).



C'est plus ou moins vrai, à un premier niveau et d'une manière générale.
Mais bon, faut aller plus loin, parce que:

Il y a peut-être de grosses erreurs de conception que je ne vois et ne
verrai jamais, mais elles sont à un tout autre niveau que
l'enchevêtrement de if, elseif et foreach sans aucune fonction
spécifique que je vois souvent, et notamment dans le code dont je parle
ci-après.



J'ai plusieur fois été induit en erreur par un code qui, au premier coup
d'oeil, avait l'air raisonnablement propre, structuré et documenté, mais
s'avérait au final être un ramassis d'âneries, d'erreurs grossières, et
d'application stupide de recette toutes faites ou de "bonne pratiques"
mal comprises et inappropriées dans le contexte - notamment certains
projets en PHP "objet" - mouarf - qui atteignent des sommets de débilité
dans le genre "j'ai rien pigé mais j'ai tout fait comme dans le livre".

Et - même si c'est bien plus rare - il m'est arrivé d'être finalement
agréablement surpris par du code qui semblait à première vue un plat de
spaghettis comme celui que tu décris ci-dessus, et s'avérait au final
être certes assez "bourrin", mais par ailleurs correct, robuste,
efficace, et globalement intelligible.


Ca dépend de ce que tu entends par « meilleur », dans quel contexte.
La concision n'est pas forcément ce qu'il y a de plus intelligent.





Je ne peux qu'appuyer. Mais bon, faut pas confondre non plus "explicite"
et "complètement con". Je tombe encore régulièrement sur des c... qui
relèvent quand même du niveau le plus abyssale d'incompréhension des
principes de base, du genre:

if <une_expression_booleenne> {
$var = TRUE;
}
else {
$var = FALSE;
}

Affligeant...

Dans ce cas, quelque soit le contexte, je peux vous te l'assurer (bon
j'étais méchant, hors commentaires et accolade, ils sont sur ~30 lignes) !



Tu nous posterais un lien sur le code en question (et éventuellement ta
propre implémentation) ?-)
Avatar
Mickaël Wolff
Bruno Desthuilliers a écrit :

Parce que PHP est codé avec les pieds !-)


Chut ! Des décideurs pressés vont t'entendre !

parce que array_flip est une "vraie" fonction - et fonctionne donc sans
effet de bord. Ca, à mon sens, c'est plutôt une BonneChose. D'autant que
je ne suis pas sûr qu'il soit possible d'implémenter efficacement ce
type d'opération réellement "en place" (c'est à dire sans créer au moins
temporairement un second tableau), contrairement à, par exemple, un tri
ou un reverse.


C'est une question d'école. Quand on a été élevé à la POO, on
s'attend à ce que l'« objet » soit manipulé.

<plug>
Tiens au fait, quelqu'un sait comment sont implémentés les tableaux de
PHP ? (ok, je pourrais regarder dans le source, mais là j'ai un peu la
flemme).
</plug>


Ce sont des hashtables.

Pas seulement. Si tu savais les horreurs que j'ai vu dans des applis de
gestion...


Comme l'usage des float pour gérer les flux monétaires ?

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Avatar
Olivier Masson
Merci pour vos réponses, c'est bien de savoir sur quoi on bosse.
N'étant pas développeur, je n'ai que peu de bonnes pratique, notamment
la poo.
Ceci dit, je me rends compte sur certains projets que de jolis dev
sortis de l'école ont tout ce qu'il faut comme acronyme à leur cv, mais
ils codent avec une bêtise incommensurable...


Bruno Desthuilliers a écrit :
Tu nous posterais un lien sur le code en question (et éventuellement ta
propre implémentation) ?-)



Ah la la... c'est que ce n'est pas très gentil tout ça...
Bon, j'ai changé le nom des variables. Je poste pas un lien ici parce
qu'ils pourraient mal le prendre (je m'étonne moi-même de tant d'attentions)
Voici la merveille donc (j'attends que tu me dises que c'est puissant et
robuste :) Tu noteras surtout la qualité des booléens). Vous aurez
compris que ça prend l'url et que ça y ajoute ou modifie une valeur en
GET, ainsi :
$url = addGET("http://www.monsite.com/rep/index.html?page=3&lang=fr",
"page", "7");

function addGET($url, $pNom, $pValeur){
$urlFinal = "";
if($pNom==""){
$urlFinal = $url;
}else{
$t_url = explode("?",$url);
if(count($t_url)==1){
$urlFinal .= $url;
if(substr($url,strlen($url)-1,strlen($url))!="/"){
$t_url2 = explode("/",$url);
if(preg_match("/./",$t_url2[count($t_url2)-1])=úlse){
$urlFinal .= "/";
}
}
$urlFinal .= "?".$pNom."=".$pValeur;
}else if(count($t_url)==2){
$addQString = "non";
$t_queryString = explode("&",$t_url[1]);
foreach($t_queryString as $cle => $NValeur){
$t_param = explode("=",$NValeur);
if($t_param[0]==$pNom){
$addQString = "oui";
}
}
if($addQString=="non"){
$urlFinal = $url."&".$pNom."=".$pValeur;
}else if($addQString=="oui"){
$urlFinal = $t_url[0]."?";
foreach($t_queryString as $cle => $NValeur){
if($cle > 0){
$urlFinal .= "&";
}
$t_NValeur = explode("=",$NValeur);
if($t_NValeur[0]==$pNom){
$urlFinal .= $pNom."=".$pValeur;
}else{
$urlFinal .= $t_NValeur[0]."=".$t_NValeur[1];
}
}
}
}
}
return $urlFinal;
}
Avatar
Olivier Miakinen
Le 05/11/2009 23:36, Olivier Masson a écrit :

function addGET($url, $pNom, $pValeur){
[...]
if(substr($url,strlen($url)-1,strlen($url))!="/"){



Ça, c'est typique de ceux qui programment « par essais et erreurs »
jusqu'à ce que ça marche, au lieu d'aller lire la doc. Tout d'abord, ils
ont l'air de penser que le troisième paramètre est une position dans la
chaîne au lieu d'être une longueur (en commençant à strlen($url)-1, la
longueur restante ne peut pas être plus grande que 1, et il est donc
inutile d'y mettre strlen($url)). Ensuite, en lisant la doc ils auraient
vu qu'on peut supprimer ce troisième paramètre quand on veut lire
jusqu'à la fin de la chaîne. Enfin, mettre -1 en deuxième paramètre est
plus simple et plus rapide que de calculer la longueur avec strlen($url)
et de lui soustraire 1.

Donc :
if (substr($url, -1) != "/") {

$t_url2 = explode("/",$url);
if(preg_match("/./",$t_url2[count($t_url2)-1])=úlse){
$urlFinal .= "/";
}



MOUHAHAHAHAHA !!!

Tu as bien fait de publier ce bout de code, ç'aurait été dommage de le
rater.

Le preg_match('/./', ...), ça vérifie par une façon extraordinairement
compliquée que la chaîne n'est pas vide. Le résultat vaut 0 si la chaîne
est vide, valeur entière qu'ils comparent avec un booléen (heureusement
pour eux, par « == » au lieu de « === »), et au final ils rajoutent donc
un '/' à la fin de cette URL si le dernier élément du tableau issu de
l'explode() est vide (c'est-à-dire, en clair, si l'URL se terminait déjà
par un '/').

Seulement, ce test ubuesque n'est fait que dans le cas où l'URL ne se
terminait justement *pas* par un '/' !

En résumé, ce code fait :
SI l'URL ne se termine pas par un '/' MAIS qu'elle se termine par un
'/', ALORS rajouter un '/'.

C'est tout simplement excellent !

Allez, je vais lire le reste, ça risque d'être drôle.


--
Olivier Miakinen
Avatar
YBM
Olivier Masson a écrit :
Merci pour vos réponses, c'est bien de savoir sur quoi on bosse.
N'étant pas développeur, je n'ai que peu de bonnes pratique, notamment
la poo.
Ceci dit, je me rends compte sur certains projets que de jolis dev
sortis de l'école ont tout ce qu'il faut comme acronyme à leur cv, mais
ils codent avec une bêtise incommensurable...


Bruno Desthuilliers a écrit :
Tu nous posterais un lien sur le code en question (et éventuellement
ta propre implémentation) ?-)



Ah la la... c'est que ce n'est pas très gentil tout ça...
Bon, j'ai changé le nom des variables. Je poste pas un lien ici parce
qu'ils pourraient mal le prendre (je m'étonne moi-même de tant
d'attentions)
Voici la merveille donc (j'attends que tu me dises que c'est puissant et
robuste :) Tu noteras surtout la qualité des booléens). Vous aurez
compris que ça prend l'url et que ça y ajoute ou modifie une valeur en
GET, ainsi :
$url = addGET("http://www.monsite.com/rep/index.html?page=3&lang=fr",
"page", "7");

function addGET($url, $pNom, $pValeur){


#argl!
}



à envoyer à
http://thedailywtf.com/
ou
http://fr.thedailywtf.com/ ça !
Avatar
CrazyCat
Olivier Masson wrote:
Voici la merveille donc (j'attends que tu me dises que c'est puissant et
robuste :) Tu noteras surtout la qualité des booléens). Vous aurez
compris que ça prend l'url et que ça y ajoute ou modifie une valeur en
GET, ainsi :
$url = addGET("http://www.monsite.com/rep/index.html?page=3&langfr",
"page", "7");

function addGET($url, $pNom, $pValeur){


[snip de l'horreur]
}



Donc c'est un truc qui date d'avant PHP4 sans quoi il y aurait un
parse_url pour simplifier.
Et par conséquent, ils ne pouvaient pas utiliser non plus
http_buidl_query :)

J'ai un gros doute tout d'un coup: le "php 1" dans le sujet, je croyais
que ça signifiait que c'est ta première question, mais en fait c'est la
version de PHP utilisée par l'agence ? :D

Bon, c'est pas beau de se moquer, je ne le ferai plus. Quoi que...

--
Réseau IRC Francophone: http://www.zeolia.net
Aide et astuces : http://www.g33k-zone.org
Communauté Francophone sur les Eggdrops: http://www.eggdrop.fr
1 2 3 4 5