Verbum veritas est

(oui, je sais, je n'avais aucune obligation de mettre implicitement un verbe à la fin, mais vous comprendrez la lourdeur plus bas)

John Nack, (dev chez Adobe) assez sarcastique, bashait sur son blog envers son propre travail en ces termes : « Photoshop [...] c'est comme les anneaux dans les coupes d'arbres : On peut deviner l'âge de chaque fonction rien qu'en regardant le design des fenêtres de dialogue ». Pour ceux qui en doutent, regardez l'évolution de la toolbar pour commencer. Faut dire que y'a eu du progrès en infographie depuis 1989 (et même plus tôt puisque une bonne partie des icônes étaient pompées au Deluxe Paint sur Amiga, lui même pompé sur MacPaint, etc...)

Reprenant pour la Xème fois mon toolkit PHP pour intégrer de nouvelles procédures, je me suis demandé quelle devait être la convention de nommage des fonctions. Majuscule initiale ? Avec ou sans underscore ? SujetVerbeObjet ou verbe_sujetobjet ? Mon manque consistance dans le sujet m'angoisse pas mal...

Et là, je me sens tout de suis mieux...

Tout récemment (justement suite à une de ces nuits blanches), je suis tombé sur ce fil de commentaires dans Slashdot

Ce commentaire donne des exemples assez rigolos.

Inconsistance des noms avec ou sans underscores (caractère souligné)
substr_compare() vs. strcmp()

Encore plus inconsistant dans les noms (position du verbe) :
file_get_contents() vs. get_html_translation_table()

Voire même parfois dans la même extension :
imagesetstyle() vs. imagecolorset()

Position changeante des mêmes attributs :
strpos(haystack, needle) vs. in_array(needle, haystack)

Le principal problème de cette inconsistance, c'est que le site de référence est souvent ralenti par les requêtes de tout le monde, et n'a même pas de ressource opensearch (la fonction de recherche de votre navigateur), comme les Wikipédia ou encore MDC. Même mon blog en a un, ou celui d'Enflammée !

Mais j'ai récemment eu un “meilleur” exemple.

Cyber-l@rgués

J'ai été chargé par un client de mettre en place un système de paiement sécurisé en ligne par carte bancaire. Jusqu'ici, rien que de très classique. Hélas, j'ai appris par la suite pourquoi plusieurs web-agencies (au moins deux de mes autres clients) refusent de bosser sur le système Crédit Mutuel/CIC.
Le CyberMut est un système de Cyber P@iement (aha, rien que le positionnement de l'@ et le mot “cyber” utilisé à toutes les sauces fait poussiéreux, voire même pue salement le marketeux dépassé dès que pensé). Son « principal avantage sur les concurrents » serait l'absence de code hors script du site web (typiquement, deux autres kits utilisent un exécutable ELF, et un autre du perl). Mais le code fourni en PHP n'a pas bougé d'un poil depuis 2003.

À tel point que les conventions de code datent de PHP3 (le kit est annoncé “PHP4.3”), utilisant des variables globales qui étaient déjà annoncées comme dépréciées, tout en générant un balisage HTML4, absolument pas prévu ni pour le XHTML, ni pour l'usage du <button></> en lieu et place du <input type="submit"> (sans le "/" final : je rappelle que leur code est archaïque), compliquant son design.

Alors évidemment, j'ai appelé en demandant l'autorisation de mettre un peu à jour leur code. « Houlà ! Non ! Surtout pas ! Ça marche tel quel, mais surtout pas toucher. ».
Grand Dieux....
Voilà qu'une boite qui est spécialisée dans la conception de ce... truc, me fait le coup du “magique”, “tabou”, “pas touche c'est sacré”.

Fallait pas...

... fallait vraiment pas me dire ça : Du coup, j'ai regardé plus profond. Et j'ai été partagé entre la totale désolation modérée d'une compassion infinie et les hurlements d'un rire démentiel à en faire ouvrir les Enfers. 

<?php
/*****************************************************************************
 *
 * CM_CIC_Paiement "open source" kit for CyberMUT-P@iement(TM) and
 *                  P@iementCIC(TM).
 * Generate CMCIC Payment Form. Sample RFC2104 compliant with PHP4 skeleton.
[...]
 * Auteur   : Euro-Information/e-Commerce (contact: centrecom@e-i.com)
 * Copyright: (c) 2003 Euro-Information. Tous droits réservés.
[...]
$stub_method = $HTTP_SERVER_VARS["REQUEST_METHOD"];

if (($stub_method == "GET") or ($stub_method == "POST")) {

    $wstub_order  = "HTTP_" . $stub_method . "_VARS";
    $stub_order  = ${$wstub_order};

}
else
    die ('Invalid REQUEST_METHOD (not GET, not POST).');
Une soupasse de grand n'importe quoi point de vue lisibilité, stabilité et sécurité.
Continuons.

Le formulaire de paiement doit avoir toutes les variables « encodées en HTML ». Vous me direz “normal”. Oui, sauf que pour eux, une balise formulaire doit commencer comme suit : 

<form method="post" name="FormulaireEncodeConforme" 
action="https&#x3a;&#x2f;&#x2f;paiement.creditmutuel.fr&#x3a;paiement">
Car si vous utilisez https://paiement... histoire d'avoir votre code lisible, houlala ! Non, surtout pas ! C'est pas sécurisé !

L'Ingénieur Informaticien, cette vocation incomprise...

Le reste contient d'autres moments de grand n'importe quoi dans les conventions de codage. Sans compter d'autres normes lues en diagonale et implémentées de traviole. Tout en imposant la lecture de l'intégralité de leur documentation, la rédaction faite de telle manière que les éléments importants soient camouflés dans le texte, pour être sûr que vous lisez l'intégralité de la documentation, parce qu'elle est importante cette documentation : des ingénieurs, pour justifier leurs émoluments et rassurer leurs égos démesurés, adorent noyer les éléments de références techniques oiseuses tout en utilisant des termes inutilement imbitables pour des concepts tout à fait simples. Donc il vous faudra lire leur prose à peu près aussi intéressante que la ré-écriture d'un ensemble de traités inter-étatiques par un ancien Président de la République pour justifier de son entrée à l'Académie Française.

Je vous fait grâce de la suite, mais sachez que tous les hébergeurs modernes proposent du PHP5, et que pour faire tourner de tels archaïsmes sur un serveur standard, j'avais plus vite fait de ré-écrire une grande partie de leurs implémentations.

Alors oui, le mécanisme bancaire semble tout à fait correct (objectivement, il n'est pas mauvais, juste que le boulot aurait gagné en efficacité et lisibilité), mais perdre du temps parce que des ingénieurs ne savent pas se remettre en cause, pondre un code propre et régulièrement mis à la page, c'est franchement une grosse perte pour tout le monde.
Parce qu'avec un code aussi peu entretenu, on pourrait croire que personne ne s'occupe d'éventuels trous de sécurité.

Et dire que des clients paient pour ça.