C’est tellement bien PHP qu’on se demande si on peu en dire du mal. Je me souviens pourtant de mes premières impressions quand je commençais à prendre en main ce langage il y a quelques années. Je me demandais pourquoi les développeurs plébiscitaient un outil qui avait manifestement très peu de rigueur dans le nommage des fonctions et dans leur syntaxe. Donc voilà, l’idée m’est venue de vous proposer un petit tour des incohérences de PHP.

Le casse-tête des dates

C’est vrai que PHP 5.2 offre une classe native DateTime pour la gestion avancées des dates. Mais à part ça, travailler sur des dates est une vraie souffrance.

Sous certaines distributions Linux, et sous Windows, les timestamps négatifs ne sont pas gérés. PHP se basant sur les timestamps systèmes, il ne gèrera donc pas les dates avant le 1° janvier 1970 sur ces plateformes. Une galère totale pour les dates de naissance par exemple. La bibliothèque Pear vient à votre secours en proposant un module spéciale date, mais c’est du lourd.

La fonction date() permet de formater une date en texte, c’est à dire de convertir un timestamp en affichage lisible pour l’utilisateur ou en chaine univoque pour SQL. Étrangement, cette fonction qui offre un large panel de formatage ne permet pas l’affichage des minutes et des secondes sans les zéro, alors qu’elle le peu pour les mois et les jours. Pourquoi ?
La syntaxe des formats locaux sont complètement différents du format date système. Par exemple date(‘i’,$ts) affiche les minutes du timestamp $t, alors qu’en formatage local il faut faire strftime(‘%M’,$ts). Pourquoi ? Mais pourquoi ? Pour couronner les différences, certains formats de l’un n’existent pas chez l’autre. Par exemple strftime() ne peut pas afficher le numéro du mois avec le zéro non significatif, alors que date() le réalise parfaitement. C’est à s’arracher les cheveux !

La fonction strtotime() est primordiale puisqu’elle convertie une chaine en timestamp. Elle sert pour travailler sur une date saisie par l’utilisateur ou d’une base MySQL. Mais pas de bol, elle tient compte du changement d’heure d’été. Ca devient un vrai drame pour faire un bête calcule de durée entre deux dates.
La fonction date_default_timezone_set() introduite en PHP 5.1.0 permet de contourner ce problème.

Des arguments dans n’importe quel sens

La fonction mktime()
Mais pourquoi avoir rangé les arguments dans l’ordre Heure, Min, Sec, Mois, Jour, Année !! ?? Ca correspond bien au format américain Mois/Jour/Année. Mais les anglais, les français, et bien d’autres pays n’ont pas ce format. Et pourquoi avoir placé les Heures au début ? Ça n’a rien de pratique. Le plus répandu, et le plus universel c’est quand même Année,Mois,Jour, puis en optionnel Heure,Min,Sec.

La fonction str_replace()
Alors que toutes les fonctions de chaine placent la chaine traitée en premier argument (ce qui a une certaine logique), la petite fonction str_replace() ne fait pas comme les autres, et c’est en dernière position que vous devez placer la chaine à traiter, après celle à rechercher et celle de remplacement.

Des noms trompeurs :
Exemples :

• reset() sert pour les tableaux. Le nommage des fonctions date s’est amélioré, en effet les nouvelles fonctions sont toutes préfixée par « array_ ».
• define() crée une constante. Ça aurait pu définir n’importe quoi, d’ailleurs dans d’autres langages ça sert plutôt à définir une variable.
• date() retourne une chaine et pas une date.

Des noms pas très bien régulés :
Exemple : strpos(), strlen() mais str_replace()

Les alias de fonction, c’est inutile :
Exemple : die() et exit()
PHP regorge d’alias superflus.

Bon ok, c’est facile de critiquer… de plus on peu voir que PHP 5 tente de redresser le tir. Le langage étant super pratique par ailleurs, on lui excuse bien facilement ses petits défauts.