Des trucs à ne pas faire...
jeudi 20 septembre 2007 :: perrick :: PHP :: 2 commentaires :: aucun trackbackEn reprenant une application existante en PHP, j'ai redécouvert un certain nombre de trucs à éviter. Voici un petit florilège.
- Modifier
$_GET
,$_POST
ou$_SESSION
. Ces variables magiques sont générées par le moteur PHP : bien sûr c'est parfois pratique de les écraser, de les modifier ou (pire) de les générer à la volée. C'est juste qu'ensuite il devient tellement facile de s'y perdre. - Ne pas utiliser
gettext
. Plutôt que de ré-inventer la roue pour la gestion des langues, sachez que ce système-là est stable, éprouvé et efficace. Sinon il existe aussi des librairies externes très bien foutues : dans les eZ Components ou PEAR par exemple. En attendant PHP6 bien sûr ;-) - Préférer
$t
à$tableau
. Surtout quand le reste du code est écrit en anglais ! Le code, c'est pour les humains qui lisent, pas pour la machine qui traduit mécaniquement et qui se tape royalement d'avoir des caractères en plus.
Vos commentaires et/ou trackbacks
Le dimanche 23 septembre 2007 à 15:24, commentaire par Katatonia :: #
"Préférer $t à $tableau." Oulah, un programme devient difficilement utilisable si les variables sont nommés avec des noms aussi peu explicites que "$t"...
Le lundi 24 septembre 2007 à 21:11, commentaire par LaurentJ :: site :: #
pour le 1, je suis d'accord.
Pour l'utilisation de gettext : j'ai pas vu plus pourri comme système de localisation d'une application. Je préfère les systèmes à clés (comme les fichiers properties à la Java ou à la Mozilla). Au moins si tu as une faute d'orthographe ou autre dans la phrase d'origine (qui sert de clé dans gettext), tu n'a pas à reconstuire les indexs de gettext. Deplus, avec gettext, tu n'es pas informé quand un texte n'est pas traduit. Franchement pas pratique à mon sens. Enfin, cette fonction est trop dépendante de la configuration du système, ce qui peut poser problème sur les serveurs dont on ne peut modifier la configuration.
> Le code, c'est pour les humains qui lisent, pas pour la machine qui traduit mécaniquement et qui se tape royalement d'avoir des caractères en plus.
Alors déjà, utiliser $t ou $tableau, ça dépend pour quoi. Pour une variable locale, ça n'a pas vraiment d'importance (c'est comme les $i pour les compteurs de boucles). Mais bien sûr il est préférable d'utiliser des noms explicites pour les propriétés d'objets, ou les variables globales. Et puis le nom $tableau est franchement inadéquate : il est préférable d'utiliser un nom qui décrit ce que contient la variable fonctionnellement parlant, qu'un nom qui décrit son type ($listeUtilisateur c'est déjà beaucoup mieux, le code source est ainsi autodocumenté, alors que $tableau, c'est quoi ? un tableau de quoi ?).
Ensuite, non, les machines, et surtout PHP, ne s'en tapent pas royalement d'avoir des caractères en plus. Les variables sont stockées dans des tables indexées en mémoire. Qui dit nom long, dit mémoire occupée en plus, donc index plus gros, donc recherche plus couteuse, donc accès à la valeur plus coûteux. Sur des sites à fort trafic, ça fait une grosse différence entre n'utiliser que des noms longs du genre $productContainedInTheCart et ou que des noms court comme $product. Pour les mêmes raisons, quand on peut se passer de variables, on évite, ça évite les opérations d'indexation, et des temps d'accès aux valeurs de variables plus long.
Ajouter un commentaire
Les commentaires pour ce billet sont fermés.