Et si PHP était audité demain afin d'en évaluer le niveau de qualité ? Il n'est pas certain que le bilan serait satisfaisant, tant la nomenclature de nommage des fonctions, voir carrément les prototypes d'appels, sont déroutants. Rapide état des lieux d'un capharnaüm.

String haystack et string needle ?

La fonction strstr() trouve la première occurrence d’une chaîne dans une autre. Son prototype d’appel est : string strstr ( string haystack, string needle )

Par contre, la fonction str_replace() qui permet de remplacer toutes les occurrences dans une chaîne utilise le prototype d’appel suivant : mixed str_replace ( mixed search, mixed replace, mixed subject [, int &count] )

Pour des raisons de cohérence, on se demande pourquoi le premier argument n’est pas la chaîne sur laquelle on désire appliquer les remplacements, le second étant la chaîne dont on recherche l’occurrence, le troisième la chaîne de remplacement, etc. Bref, on le voit ici, la chaîne correspondant à l’occurrence cherchée se trouve alternativement en dernier et en premier argument.

Underscore ou non ?

Toujours en se basant sur les deux fonctions précédentes, il est étonnant de noter que certaines fonctions comportent des underscores (str_replace(), str_repeat(), str_shuffle(), etc.) et d’autres non (strlen(), strpos(), strtolower(), etc.). D’autres exemples sont encore plus flagrants. Par exemple, la fonction stripslashes() qui a pour but de supprimer les anti-slash d’une chaîne et la fonction strip_tags() qui a pour but de supprimer les balises HTML et PHP d’une chaîne. Pourquoi un underscore pour l’une et non pour l’autre ? Même chose pour la fonction base64_decode() (et sa fonction connexe base64_encode()) et urldecode() (et sa fonction connexe urlencode()).

Singulier ou pluriel ?

Certaines fonctions de PHP sont au pluriel, d’autres non. Et parfois, la cohérence est contestable. Par exemple array_diff_key() calcule la différence de deux tableaux en utilisant les clefs pour comparaison et array_fill_keys() qui remplit un tableau avec des valeurs en spécifiant les clefs.

Tiens, et puisque nous en sommes à regarder les tableaux, jetons un œil à array_search(). Son prototype d’appel est : mixed array_search ( mixed needle, array haystack [, bool strict] )

A rapprocher de celui de strstr() vu précédement. L’occurrence cherchée (la fameuse needle) est désormais en premier argument dans le cas de array_search(). C’était l’inverse pour strstr() ! Pourtant ces fonctions sont très similaires. Seule la cible de la recherche change (une chaîne pour strstr() et un tableau pour array_search()...).

Mais revenons à l’étrange logique de choix entre singulier et pluriel et quittons un instant les prototypes de fonctions pour nous intéresser aux quelques variables superglobales que comporte PHP. Que penser, en particulier, de $_FILES (pluriel) et $_COOKIE (singulier)…

To ou 2 ?

Dans le même esprit, le cas de la fonction strtolower() (et de sa fonction connexe strtoupper() ) visant à transformer une chaîne en minuscule (respectivement en majuscule) est intéressant. Il est à rapprocher du cas de la fonction bin2hex() dont le but est de convertir une donnée binaire en hexadécimal. On peut également citer la fonction nl2br(), très courante, qui sert à insérer un <br/> à chaque fin de ligne ou encore les fonctions de conversion de degrés en radians, deg2rad() (respectivement rad2deg()).

Cohérence encore…

Et puisque nous parlions de la fonction bin2hex(), si nous désirons convertir une donnée décimale (et non plus binaire) en hexadécimal, c’est la fonction dechex() qu’il faudra utiliser (et non une hypothétique fonction dec2hex() qui n’existe pas…).

Et cohérence toujours !

Pour finir, sortons à nouveau d’un simple passage en revue de la logique de nommage et des prototypes des fonctions supportées par PHP pour nous intéresser aux paramètres de compilation de PHP. Voici par exemple le ./configure que j’ai utilisé pour compiler la dernière version 5.2.1.


'./configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-mysql=/usr/local/mysql/' '--with-mysqli=/usr/local/mysql/bin/mysql_config' '--with-pgsql=/usr/local/pgsql/' '--enable-pdo' '--with-openssl' '--enable-bcmath' '--with-bz2' '--enable-pic' '--enable-calendar' '--enable-ctype' '--enable-ftp' '--enable-gd-imgstrttf' '--with-gd' '--with-freetype-dir=/usr/local' '--with-png-dir=/usr/local' '--with-jpeg-dir=/usr/local' '--with-gmp' '--enable-trans-sid' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-memory-limit' '--disable-debug' '--with-zlib=/usr' '--with-xml' '--without-pear' '--with-dom' '--with-dom-xslt' '--with-dom-exslt' '--enable-mailparse' '--with-mcrypt' '--enable-simplexml' '--enable-mbstring=all' '--with-ldap' '--with-pspell' '--with-ncurses' '--with-curl' '--with-xsl' '--with-pdo-mysql=/usr/local/mysql/' '--with-pdo-pgsql=/usr/local/pgsql/' '--with-imap=/usr/local/imap-2004g'

Que penser des --enable (respectivement --disable) et des --with (respectivement --without) ? L’entropie n’est pas loin !

Evidement, il est toujours un peu facile de faire ce genre de constat critique avec du recul. PHP est un projet en constante évolution, animé par de nombreux contributeurs. Et c'est tant mieux ! Mais, effet induit, veiller à la cohérence globale d'un tel projet n'est pas une mission facile. La preuve.

Pourtant, de nombreux projets (dont certains langages) y arrivent. Pourquoi n'est-ce pas le cas de PHP ? Certainement pour diverses raisons. En premier lieu, de part l'absence de réelle démarche qualité lors de la génèse du langage. Mais aussi parceque PHP manque probablement d'un réel leader (ou d'un leader par branche) seul à même d'entériner et valider toutes nouvelles contributions et changements majeurs. C'est le cas d'un projet comme Linux pour lequel, de mémoire, seuls Linus Torvalds et Alan Cox ont un rôle d'arbitrage (parfois sévère). En dernier recours, c'est eux qui décident si une contribution sera retenue ou non. C'est aussi eux qui décident si le code peut-être distribué et ceci uniquement s'ils estiment qu'il est suffisament mature et fiable pour l'être, etc. Dans l'édifice PHP, les prises de décisions sont souvent plus collégiales...

Est-ce pour autant trop tard ? Oui et non. Au niveau nommage, il serait toujours possible, afin de garantir au moins un temps la sacro-sainte compatibilité arrière (et éviter les BC break), de fabriquer des alias. PHP en contient déjà pas mal. Ainsi, la fonction strpos() pourrait être remplacée progressivement par str_pos() (si le choix de privilégier l'underscore était retenu). Idem pour la fonction dechex(). Un alias pourrait permettre de la remplacer progressivement par dec2hex() (si le concept du 2 transitionnel était validé). Par contre, l'impact de nouveaux alias pénaliserait probablement le parseur. Et les alias ne permettront pas de changer les prototypes (et donc les incohérences sur le positionnement de certains arguments, comme vu plus haut). Quant au ./configure, améliorer l'ensemble est tout à fait envisageable. Il semblerait même opportun de s'y plonger tant il est pénible de ne jamais savoir s'il faut opter pour un --with ou un --enable !