mardi 2 octobre 2007
PHP, outil de torture pour développeur
Par haypo, mardi 2 octobre 2007 à 01:04 :: Programmation
Je travaille actuellement sur le projet Nuface pour INL. Environ cinq personnes travaillent ou ont travaillé sur ce projet écrit en PHP (3/4) et Python (1/4). Le qualité du code source laisse à désirer. Je fais de mon mieux pour simplifier le code tout en le rendant plus simple à comprendre, mais c'est une tâche difficile et pénible. J'ai alors cherché des outils pour m'aider dans ma tâche.
Analyse statique de code
J'ai cherché des outils d'analyse statique de code pour PHP. Malheureusement, je n'en ai trouvé que quatre : Pixy, SWAAT, php-sat et PHP String Analyzer (phpsa). Les deux premiers sont dédiés à la sécurité, ce qui ne m'intéresse pas (injection SQL et XSS). phpsa est un drôle de projet dont je n'ai pas compris l'intérêt, et j'ai donc finalement testé php-sat. L'installation est longue car il n'existe aucun paquet Ubuntu Feisty, ni pour php-sat, ni pour les nombreuses dépendances. Ordre dans lequel il faut les installer (de mémoire) :
- aterm (2.5)
- sdf2 (2.4)
- strategoxt (0.17)
- php-front (0.1pre401)
- php-sat (0.1pre344)
Une fois que j'ai terminé de tout compiler et installer, j'obtiens ce joli message :
$ php-sat -i index.php
[ php-sat | error ] invalid box:
KnownString{SafetyLevel([KnownString])}
Je ne comprend rien à ce message d'erreur cryptique que j'obtiens qu'importe le fichier passé en argument. Ayant passé deux heures à tout installer, je suis plutôt déçu et décide d'abandonner. La bonne pratique serait de contacter Eric Bouwers, l'auteur de php-sat pour lui rapporter mon problème, mais je ne l'ai pas (encore) fait.
Note : L'outil SWAAT a l'air d'être un bon outil pour trouver rapidement des failles de sécurité dans vos applications.
Eclipse et PDT
Un ami — feth — m'a montré les fonctions de refactoring de l'environnement de développement Eclipse. Bluffé par la facilité de renommer une variable ou créer une sous-fonction, je me suis décidé à l'installer pour pouvoir l'utiliser sur du code PHP. Une petite recherche m'a guidé vers PHPEclipse et PDT. Le premier n'est plus développé en faveur du second qui est sponsorisé par Zend, entreprise à l'origine du langage PHP. Zend emploie Yossi Leon pour travailler sur ce projet à plein temps.
J'ai d'abord installé Eclipse via Ubuntu : c'est la version 3.2 qui est disponible. Or quand j'ai voulu ajouter le greffon PDT, j'apprend qu'il faut la version 3.3 d'Eclipse. D'ailleurs, je réalise au passage que PDT est sorti en version 1.0 le 18 septembre dernier, c'est donc tout frais !
J'ai alors installé Eclipse en téléchargeant Eclipse Classic (eclipse-SDK-3.3.1-linux-gtk.tar.gz). Pour importer le projet Nuface, j'ai d'abord installé Subclipse, le greffon Subversion.
Finalement, tout s'est bien emboîté : Nuface s'ouvre à merveille dans Eclipse additionné de Subclipse et PDT. Eclipse affiche directement des avertissements sur la documentation écrite en docbook (format basé sur XML). En corrigeant l'erreur sur le charset incorrect, il arrive ensuite à détecter les erreurs de DTD (docbook). Chapeau !
Enfin, quand je cherche la fonction de refactoring « créer une sous-fonctions » — après deux heures d'installation — je découvre que la fonction n'existe tout simplement pas ! Seule la fonction pour renommer une variable ou une fonction est disponible dans PDT 1.0. Or j'avais installé Eclipse uniquement pour cette fonction... grosse déception.
Plantage PHP
Pour finir en beauté, aujourd'hui j'ai trouvé un bug critique dans l'interpréteur PHP. J'ai mis trois heures à isoler un bug ridicule qui fait planter le processus Apache (child pid 12946 exit signal Segmentation fault (11)). Les détails du plantage sont disponibles dans mon rapport de bug (#42817). Je pense que vu la popularité de PHP, ce bug peut être une faille de sécurité.
PHP est à vomir
Étant un programmeur de longue date, je suis très déçu de PHP. Langage crée en 1994, sa dernière version majeure (PHP5) élimine quelques défauts du modèle objet et comble certaines lacunes (ex: gestion des exceptions). Mais PHP 5.2 ne supporte pas Unicode et est vraiment trop laxiste selon moi. En particulier, accéder à une variable indéfinie ou à une clé inexistante d'un tableau devrait être proscrit. Pour que la programmation en PHP soit supportable, il faut travailler dans un niveau d'avertissement maximum : « error_reporint(E_ALL); ». Je vous conseille de jetter un œil au fichier debug.php de Nuface, il contient en particulier un gestionnaire d'erreur écrit PHP (nuface_error_handler).
Bon, moi je vais retourner coder des tests unitaires pour SimpleTest... Pour information, la version CVS offre une méthode expectException(), nécessaire pour pouvoir tester les exceptions.