Ne jamais prendre un article pour parole d’évangile

Comme vous l’avez constaté, j’ai très peu de temps libre en ce moment mais la lecture d’un article publié par IBM sur les méthodes de déboggage d’un script PHP m’a fait bondir.

Le niveau général de l’article est assez faible. Il n’aborde par exemple pas certaines possibilités plus pratiques que la fonction print comme les fonctions var_dump, print_r et debug_backtrace. Mais voici l’extrait qui m’a particulièrement dérangé :

The error_reporting variable has a default value of E_ALL. This displays everything from bad coding practices to harmless notices to errors. E_ALL is a little too picky for my liking in the development process because it clutters the browser output by displaying notices on the screen for small things like uninitialized variables. I prefer to see the errors, any bad coding practices, but not the harmless notices. Therefore, replace the default value of error_reporting as follows: error_reporting = E_ALL & ~E_NOTICE

L’auteur déclare qu’il préfère n’avoir que les mauvaises pratiques de codage et non pas toutes les erreurs sans gravité comme celles des variables non initialisées. C’est assez incroyable qu’en prêchant pour les bonnes pratiques de développement, il puisse écarter l’une des principales : toutes les variables doivent être initialisées. Si le réglage par défaut du paramètre error_reporting est à E_ALL, ce n’est pas pour embêter le monde mais pour inciter à coder proprement.

Je trouve vraiment dommage qu’un article se proposant de donner des conseils afin de mieux débogger ses scripts en prodigue un si mauvais et parfaitement contre productif. Voilà encore une preuve que ce n’est pas parce qu’une chose est écrite qu’elle est vraie.

Ce contenu a été publié dans PHP. Vous pouvez le mettre en favoris avec ce permalien.

7 réponses à Ne jamais prendre un article pour parole d’évangile

  1. NiKo dit :

    Ouais, on dirait que le type vient de découvrir php3…

    Par contre le coup du point d’arrêt dans Eclipse, je connaissais pas.

  2. Vincent dit :

    Surtout que ce petit message est le seul moyen de se prémunir contre les fautes de frappe dans PHP. À moins que ce programmeur soit un dieu vivant avec son clavier, je pense qu’il changera rapidement d’avis.

  3. Greg dit :

    Rhoooo … il est juste payé par des cabinets d’audit en sécurité pour que ces derniers puissent encore vivre pour les prochaines années ! :-p

  4. nico dit :

    Bonjour,

    Je confirme, depuis que je code en E_ALL mes débogages et donc mes devs sont HYPER plus rapides et les erreurs – comme dit plus haut – liées à des fautes de frappe sont maintenant inexistantes. car franchement une grande partie des petites erreur de codage sont souvent liées à des fautes de frappe. et dans le genre faire la différence entre maVar et maVAr est souvent difficile à voir dans le flot de code sans un message "uninitalized variable maVAr"

    Nicolas

  5. Piou2fois dit :

    Hum, rien à voir avec le post, mais JMF, ça te dirait pas d’installer le plugin spamplemousse pour dotclear ?
    http://www.dotclear.net/forum/vi...
    J’ai installé ça hier, déjà 10 spam bloqués

  6. pascaltje dit :

    je viens de corriger un bug après 6 heures de recherche, le niveau de l’article en anglais me fait rire jaune :/

    une autre fonction pratique pour debugguer:
    get_defined_vars()
    fr2.php.net/manual/fr/fun…
    elle renvoie toutes les variables definies.

  7. zefredz dit :

    Comment peut-on débugger en ~ E_NOTICE ?!?

    C’est ce qui permet de détecter 90% des erreurs d’inattention et des fautes de frappes, c’est à dire, chez moi, 99% des causes de bugs.

    Du coup, cet article perd pas mal de crédibilité à mes yeux…

Les commentaires sont fermés.