Mauvaise connaissance du Php, mauvaises habitudes issues d'autres
langages, ou simple inattention: parsemer son code d'erreurs, plus
ou moins graves, est hélas à la portée de tout
le monde. Du simple ralentissement, à la chute brutale des
performances, il n'y a parfois qu'un pas, vite franchi.
Les origines de ces erreurs sont diverses et nous ne prétendons
pas toutes les identifier en un seul article. Voici cependant une
liste d'erreurs importantes, dont les causes et conséquences
sont suffisamment variées pour se rendre compte de la facilité
avec laquelle elles peuvent être introduites dans un programme.
Tutoriel mis à jour le 21/11/2001.
1) Réinventer la roue
Une erreur classique lorsqu'on découvre un langage : avoir
tendance à tout réécrire soi-même au
lieu d'utiliser les fonctions prévues à cet effet.
Deux conséquences à cela :
- L'exécution du programme est ralentie.
- Votre code perd en lisibilité.
Vous souhaitez inverser une chaîne de caractères ?
Calculer sa longueur ? Avant de foncer tête baissée
dans des boucles "for" et autres variables temporaires,
parcourez la documentation !
Php est un langage très riche en termes de fonctions,
il est donc illusoire de connaître toutes celles qui sont
disponibles dans tous les domaines, sans parler de leur syntaxe.
La documentation est consultable
en français ou téléchargeable sous différents
formats sur le site de référence : Php.net
Avec une telle documentation, en quelques secondes, nous avons accès
à "strrev" et "strlen" deux fonctions
qui ne pénaliseront pas les performances et nous feront gagner
un temps de développement souvent précieux.
En utilisant des fonctions prévues par le langage pour ce
que vous souhaitez faire, vous éviterez en plus à
ceux qui reliront votre code de se demander pourquoi vous avez utilisé
vos propres fonctions et pas celles qui sont déjà
disponibles.
Il existe également de nombreux sites dédiés
au Php sur le web tels que phpInfo.net
(dont le forum est très actif), PHPIndex.com...
Citons également PHPBuilder,
en anglais, qui offre un contenu très riche.
Enfin, pour les amateurs de newsgroups, vous trouverez sur fr.comp.infosystemes.www.auteurs.php
de quoi vous dépanner en cas de problème. Ce newsgroup
francophone est accessible via Foorum
par exemple.
2) Oublier la convention de nommage
Lorsque vous programmez, pensez toujours à ceux qui consulteront
votre code par la suite. Cela paraît évident dans le
monde professionnel (turn-over, changements de mission), mais il
est bon de l'appliquer chez soi aussi. Il sera alors plus simple
pour un programmeur tiers de rejoindre éventuellement le
projet personnel que vous développez, ou de publier votre
code par exemple.
A moins que vous ne souhaitiez "crypter" vos lignes de
code avec un algorithme très personnel, il est conseillé
d'utiliser une convention de nommage pour vos variables et autres
fonctions.
Choisissez des noms ni trop longs : "$email_du_destinataire",
ni trop courts : "$edd", mais par exemple (deux
mots maximum) : "$email_dest".
Attention ! Le Php fait la différence entre "email_dest"
et "Email_dest", il convient donc dès le départ
de votre projet de définir comment les majuscules doivent
être utilisées si besoin. Il ne faut évidemment
pas changer d'avis en cours de route...
Si vous travaillez en équipe, rédigez pourquoi pas
un document de référence auquel chaque membre
se reportera pour nommer ses variables. Vous pouvez choisir de faire
commencer le nom de chaque variable transmise par URL comme ceci
: "url_var", idem pour les formulaires "form_var",
ainsi la provenance de la variable est connue sans même de
notes explicatives au sein du code.
Ce qui s'applique pour le nommage des variables, s'applique également
au monde des fonctions. Pour elles, le choix d'un verbe est
une bonne chose : "verifie_formulaire" ou pourquoi pas
"check_form" si vous trouvez la version anglaise plus
concise.
A consulter également, la convention
de nommage du Php group.
3) Ne pas commenter son code
A quoi bon commenter son code ? Après tout vous savez ce
que vous faites non ?
C'est une très mauvaise idée de concevoir la documentation
de la sorte.
D'abord pour vous. L'algorithme qui vous semble évident aujourd'hui
peut ne plus l'être du tout deux mois après. Un grand
classique...
Lorsque vous écrivez des scripts complexes, il est important
de décrire ce que vous faites... Mais pas n'importe comment.
<?
// Affiche le nom de l'internaute
et passe à la ligne
echo("Votre nom : $nom<br>");
?>
Ce type de commentaire, sauf cas exceptionnel, n'a pas lieu d'être.
En tout cas pas sur un projet dont les développeurs sont
des professionnels. Réservez vos commentaires pour des fonctions
complexes ou des morceaux de code dont le fonctionnement n'est pas
évident.
Si vous connaissez JavaDoc, retrouvez son semblable dans le monde
Php. PHPDoc
peut en effet lui aussi générer de la documentation.
Enfin, dissociez le commentaire destiné à éclairer
le lecteur sur le fonctionnement global d'une fonction (quelques
mots placés avant la définition de la fonction suffisent),
du commentaire, plus pointu, destiné à expliquer comment
les choses se passent. C'est la différence entre le "A
quoi ca sert ?" et le "Comment ça fonctionne ?".
4) Utiliser " printf " à
toute occasion
Nous parlions de mauvaises habitudes en introduction, voici un
exemple où des programmeurs "C" peuvent être
tentés d'utiliser la fonction "printf"
à la place de la fonction "print".
Sur la documentation on peut lire pour les fonctions "printf"
et "print" respectivement "affiche une chaîne
formatée" et "affiche une chaîne".
Cela signifie que "printf" ne doit être utilisée
que lorsque la chaîne de caractères que l'on cherche
à afficher contient des valeurs que l'on souhaite "formater",
par exemple :
Un euro, arrondi à 2 chiffres apres
la virgule vaut :<br>
<?
$euro = 6.55957;
printf ("%.2f\n FF<br>",
$euro);
?>
Par contre pour afficher...
Les membres de l'équipe sont :
<?
$dev1 = "Anne-Sophie R.";
$dev2 = "José F.";
$dev3 = "Pierre GB";
print("$dev1 $dev2 $dev3");
?>
... il faut utiliser "print" car il n'y a pas de chaînes
à formater.
Rappelez-vous qu'avant d'afficher la chaîne de caractères,
la fonction "printf " la formate systématiquement,
ralentissant au passage l'exécution.
La commande "echo" vous permet également d'afficher
un résultat. Cette commande n'est cependant pas une fonction
et ne peut donc pas être utilisée au sein d'une expression.
En ce qui concerne la vitesse d'exécution, "echo"
est en théorie plus rapide que "print", notamment
parce qu'elle ne retourne pas de résultat.
5) Ne pas se limiter en variables temporaires
Selon vous, le code suivant est-il correct :
<?
// Recuperation des prix d'aujourd'hui :
$today = 20011113;
$req="select prix_fraise, prix_framboise, prix_pomme from prix_fruits
where
prix_date = $today";
$idreq=mysql_query($req,$idconnect);
// On admet que la connection s'effectue correctement et que la
requête ne ramène
// qu'un seul tuple
$row=mysql_fetch_array($idreq)
$px_fraise = $row[prix_fraise];
$px_framboise = $row[prix_framboise];
$px_pomme = $row[prix_pomme];
echo("Prix des fraises : $px_fraise<br>");
echo("Prix des framboises : $px_framboise<br>");
echo("Prix des pommes: $px_pomme<br>");
?>
Syntaxiquement parlant, ce code est correct, le traitement sera
effectué. Mais toutes nos variables nous sont-elles utiles
?
Si on considère ce programme comme complet, alors non, nous
avons utilisé trois variables "temporaires" de
trop, et cela ralentit le traitement de notre programme.
25% de temps d'exécution supplémentaire, c'est ce
que l'on risque si notre script Php comporte trop de variables temporaires.
Il est donc intéressant de ne pas multiplier celles-ci inutilement.
Voyons comment s'en passer dans notre exemple :
(Seule la partie modifiée est réécrite)
<?
$row=mysql_fetch_array($idreq)
echo("Prix des fraises : $row[prix_fraise]<br>");
echo("Prix des framboises : $row[prix_framboise]<br>");
echo("Prix des pommes: $row[prix_pomme]<br>");
?>
En règle générale, une variable temporaire
est utile si elle contribue à améliorer la lisibilité
de votre code (lorsqu'elle remplace une longue expression par exemple).
De plus elle doit être utilisée au moins deux fois.
Si aucune de ces deux conditions n'est réunie, c'est que
vous n'en avez pas besoin !
La seconde partie de ce tutoriel se
trouve ici.
|