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.

jeudi 1 décembre 2005 à 15h13 - PHP

Rétroliens

Aucun rétrolien pour le moment.

Les rétroliens pour ce billet sont fermés.

Commentaires

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.

NiKo le jeudi 1 décembre 2005 à 19h32

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.

Vincent le vendredi 2 décembre 2005 à 10h57

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

Greg le vendredi 2 décembre 2005 à 11h38

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

nico le dimanche 4 décembre 2005 à 14h06

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

Piou2fois le jeudi 8 décembre 2005 à 08h21

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.

pascaltje le jeudi 8 décembre 2005 à 14h57

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...

zefredz le lundi 12 décembre 2005 à 12h21