Discussion :

[jmnicolas]

cela montre surtout que tu n'as pas la moindre idée du contenu d'un article de Myers publié en 79.

Tu m'excuseras, mais moi j'avais un an en 1979
Et l'informatique est un champ tellement vaste, qu'on est pas tous supposés avoir lus les écrits de Myers, il y a déjà bien assez à lire pour devenir un programmeur moyen.

Toujours est il que refuser d'utiliser un debugger (en admettant qu'il soit de qualité correcte) c'est se priver de l'outil adéquat.

Mon ex-femme a bien réussit à monter un meuble avec une Mag-Light en guise de marteau, toutefois elle serait la première à reconnaitre que ça aurait été plus pratique avec un marteau (je vous rassure, c'est pas parce qu'elle a massacré ma Mag-Light qu'on a divorcé ).

[TropMDR]

Il me semble que s'ils ne développent pas avec un débogueur, c'est :
...
-soit parce qu'ils sont fermés dans leur esprit, et ne veulent pas progresser en utilisant un outils complexe. Ils ont un blocage purement idéologique.

Effectivement, ne trouver comme seul explication à la question "pourquoi ne fait-il pas comme moi" que "c'est parce qu'il est fermé dans son esprit", c'est une bonne preuve d'ouverture du tiens ! Surtout face à des gens qui font évoluer l'informatique en créant de petits langages, comme C++ par exemple...

[Chatanga]

Je ne sais pas en quoi consiste la vie de tous les jours de ces grands esprits, mais ça doit sans doute être assez différent du quotidien des développeurs plus communs (doués et moins doués). Je ne pense pas qu'ils passent énormément de temps à lire le code de "qualité industrielle" écrit par d'autres ou bien soit forcés d'utiliser le nième framework en carton développé en interne (non documenté, encore jamais utilisé sur d'autres projets, etc.). Après tout, pour moi, un débuggeur sert avant tout à comprendre le fonctionnement d'un code incompréhensible et / ou qu'on ne connaît pas ; il ne sert pas à en écrire du correct. Pour ça, des types comme Donald Knuth préfèrent un crayon, du papier et un coin tranquille pour bosser au calme. Il a même arrêté d'utiliser l'email pour éviter de perdre son temps avec des problématiques trop superficielles.

[noOneIsInnocent]

J'avoue que j'ai aussi du mal avec les débuggers. Je préfère les fichiers de logs et avoir une vue d'ensemble de la cinématique

[spidermario]

Avec un langage tel que Haskell et des implémentations comme GHC, le besoin d’utiliser un débogueur est considérablement diminué.

En cas de problème : "ghci youpi.hs", et voilà le module chargé dans la boucle intéractive où vous pouvez tester chaque élément du programme isolément (avec auto-complétion des symboles disponibles ).

Vous pouvez ensuite apporter des modifications au programme dans votre éditeur externe et entrer ":reload", et vos modifications sont prises en compte. Vous pouvez alors tester à nouveau.

[TheDrev]

je n'utilisait pas de debiggeur jusqu'a l'année dernière, la raison principale est que mes cheres professeurs n'en ont meme pas prononcer le mot pendant mes etudes.
Avec des langages type python.perl.ruby on peut a la limite s'en passer, mais pour trouver d'ou viens un plantage au runtime quand vous programmer en C, il faut plus que des prints

[Kelevra]

Quand je code en COBOL, avec IBM PCOM, il n'y a pas de débuggeur !
Il faut placer des DISPLAY, aux points clé de l'application ou du module.

Par contre quand je code en C#, le débuggeur de VS est toujours le bienvenu.

Si le débuggeur est là pourquoi ne pas l'utiliser ?

Quand il n'y en pas, on se débrouille autrement !

[b_zakaria]

Le débogage sous visual studio est vraiment pas mal: le pas à pas permet tout bêtement d'éviter de mettre l'équivalent de je ne sais combien de prints partout (c'est ce que je faisais avec le C).

[tomlev]

Le débogage sous visual studio est vraiment pas mal: le pas à pas permet tout bêtement d'éviter de mettre l'équivalent de je ne sais combien de prints partout (c'est ce que je faisais avec le C).

Pour moi, les énormes avantages du debugger de VS sont :
- la fenêtre Espion (Watch) : permet d'examiner chaque objet en détail, y compris ses membres privés
- la possibilité de "sauter" des instructions ou de revenir en arrière arbitrairement
- le "edit and continue" : permet de modifier le code à la volée sans avoir à recompiler. Super pratique quand on réalise qu'on a fait une erreur alors que le programme est déjà en train de tourner (malheureusement ça ne fonctionne pas dans tous les cas, par exemple ça ne marche pas dans un type ou une méthode générique, ni quand il y a des méthodes anonymes dans la méthode en cours)

En tous cas je pourrais difficilement envisager de me passer d'un debugger... Je l'ai fait quand je codais en C sous Solaris (encore qu'il m'arrivait occasionnellement de lancer un gdb), et quand je faisais du PHP, mais c'était vraiment pénible...

[ratomms]

Je debug mon programme avec printf.

[jokoon]

Honnetement je n'ai jamais vraiment compris l'interet d'un debugger.

Il y a aussi une citation qui dit "un debuger n'enleve pas les bug, il les fait defiler au ralenti"

Je crois pas que ces gens qui inventent des languages ont "plus de stack" ou quelque chose dans le genre.

C'est peut etre parce que j'ai appris a programmer sous linux avec la ligne de commande, mais meme, je trouve plus sense d'afficher des valeurs et des messages dans une console plutot que d'afficher tout ce qui s'est passe dans un programme, et de laisser le programmeur regarder le programme "au ralenti".

Et je trouve meme beaucoup plus pertinent de bien penser son code, meme si evidemment il est plus pertinent de relire son code que d'utiliser un debugger.

En revanche, un individu aura toujours du mal a relire le code d'un autre, donc je vois mal comment un programmeur ne pourrait pas relire son propre code.

[jblecanard]

Honnetement je n'ai jamais vraiment compris l'interet d'un debugger.

Il y a aussi une citation qui dit "un debuger n'enleve pas les bug, il les fait defiler au ralenti"

[...]

C'est peut etre parce que j'ai appris a programmer sous linux avec la ligne de commande, mais meme, je trouve plus sense d'afficher des valeurs et des messages dans une console plutot que d'afficher tout ce qui s'est passe dans un programme, et de laisser le programmeur regarder le programme "au ralenti".

Ce n'est aucunement une critique, mais ça prouve que tu n'as jamais vraiment utilisé de débugger. Le programme ne tourne pas "au ralenti". Il ne s'arrête sur des breakpoints que si tu le demandes. La plupart du temps, celà revient exactement au même que de faire défiler des valeurs, à ceci près que tu n'as pas besoin d'ajouter des instructions dans ton code, et que tu peux faire des "pauses" sans utiliser des instructions système dégueu.

Un débugger permet de filtrer, extraire et classe des informations dont on peut avoir besoin, il ne te balance pas une pâtée immangeable (à moins de ne pas savoir s'en servir). Bien sûr qu'il ne corrige pas les bugs puisqu'il ne modifie pas le code ! C'est un outil de diagnostic.

J'ai aussi appris sur linux en ligne de commande. Si ça peut t'encourager à essayer...

meme si evidemment il est plus pertinent de relire son code que d'utiliser un debugger.

L'utilisation d'un debuggeur inclus la relecture de ton code. Tu le vois s'exécuter, c'est une relecture enrichie, et en aucun cas appauvrie.

Globalement, je pense qu'il est difficile de désavouer les débuggers si on n'a pas un minimum d'expérience avec.

[Chatanga]

Indépendamment de l'intérêt plus ou moins marqué qu'on peut trouver à un debuggeur, je ne vois pas comment certains font pour s'en passer complètement (ou bien ils exagèrent pour forcer le trait). Par exemple, dans le cas d'une bibliothèque tierce, on peut évidemment lire son code mais je me vois mal y ajouter des "printf" et la recompiler. Je ne prendrais d'ailleurs même pas cette peine pour explorer un bug dans le code d'un module maison mais dont le projet n'est pas ouvert sous mon EDI. Dans un tel contexte et pour un besoin aussi basique, je vois mal comment on peut se détourner d'un debuggeur (à part s'il est vraiment mal intégré à son EDI).

Honnetement je n'ai jamais vraiment compris l'interet d'un debugger.

Il y a aussi une citation qui dit "un debuger n'enleve pas les bug, il les fait defiler au ralenti"

Pour moi, c'est justement l'intérêt d'un débuggeur. Non pas corriger magiquement un code évidemment, mais pouvoir le faire tourner au ralenti, avec la touche pause et la capacité de faire l'équivalent de tas de "printf" dans tous les sens. Ca n'est pas miraculeux mais c'est quand même plus simple de comprendre un mécanisme qu'on ne comprend pas en le regardant fonctionner, non ? Plus simple que de partir des seuls résultats en sortie et son plan de construction. Bien-sûr, une fois qu'on sais précisément comment tourne (ou plutôt devrait) un code, le débuggeur devient parfois encombrant.

[EtherOS]

Dans le Language Qt/C++ que J'utilise actuellement dans mon projet , il n'est plus nécessaire de debugger en utilisant soit le gdb de Linux , ou l'assistant de debugage car le qDebug() fait le travail parfaitement .

[6-MarViN]

Je code en C/C++ et j'utilise rarement de debugger. Si mon programme ne fait pas ce que je veux, je regarde ca a la main ou au printf. Si mon programme plante, je fait juste un coup de valgrind pour localiser le plantage et ensuite printf. Je pense qu'on a pas besoin de debbuger si on connait parfaitement son programme ce qui a mon avis est le cas de ces developpeurs.

(desole pour les accents : clavier qwerty).

[maxime1452]

Etudiant en BTS IRIS (informatique réseaux pour l'industrie), je n'utilise pas le débogueur intégré de NetBeans car depuis son installation il ne fonctionne pas sur ma machine. Du coup j'ai pris l'habitude de déboguer en printf et cout.

[silfride]

Etudiant en BTS IRIS (informatique réseaux pour l'industrie), je n'utilise pas le débogueur intégré de NetBeans car depuis son installation il ne fonctionne pas sur ma machine. Du coup j'ai pris l'habitude de déboguer en printf et cout.

Je programme depuis des années avec le langage Java sous l'IDE NetBeans et le débogueur fournit est très utile pour localiser l'erreur dans le déroulement d'un programme, puisque dés fois même avec des Printf ca ne suffit pas a appréhender l'erreur.

[yan]

Pour un code fait par eux pourquoi pas.
Mais pour un code fait par quelqu'un d'autre, cela me surprend.

Après c'est une habitude.
Les avantages que je vois à la méthode printf c'est

• obligation à bien connaitre et comprendre l'ensemble du code (et donc à bien réfléchir sur ce que tu veux vérifier).
• possibilité de faire un débogage en release.
• plus proche de l’exécution réelle du programme.

Après avoir fait les deux dans le monde professionnel, je préfère largement un débogueur +ide et quelques printf quand le debuggeur ne m'aide pas. L'utilisation du debuggeur simplifie beaucoup de chose et parfois permet de chercher et comprendre un bug en tâtonnant. Mais son utilisation borne le fonctionnement de l’exécution (la zone mémoire est différente, les pointeurs n'ont pas la même valeur, certaine valeur non initialisé ne change pas entre deux exécution, ...). Ce qui fait passer à côté de certain bug.

Pour résumer, je trouve que les deux se complète.

[Nebulix]

Je garde un souvenir ému de Turbo Pascal 3.0 où, en cas de division par zero, par exemple, le curseur venait toujours se placer sous le / correspondant.
Je n'ai rien vu depuis d'aussi efficace.

[Luckyluke34]

[B][SIZE="4"] Comment expliquez-vous que ces « masterminds » disent ne pas utiliser des débogueurs interactifs ?

Parce qu'ils font du TDD ?

Le développement dirigé par les tests unitaires réduit drastiquement le besoin d'avoir recours au debugger. Le cycle incrémental red/green/refactor et les indications données par l'outil d'exécution de tests unitaires deviennent le debugging.

Dans un récent podcast, Kent Beck, créateur d'eXtreme Programming, parle d'un gourou de la programmation de compilateur qu'il admire beaucoup (j'ai oublié son nom) et qui mentionne un ratio de lignes de tests souvent égal à 10x le nombre de lignes de code pour les programmes complexes comme les compilateurs.