Discussion :

[I_believe_in_code]

Un débogueur est valable pour les débutants, pour se former à la compréhension du langage. Il vous fait perdre du temps mais cela est nécessaire pour votre formation. Par la suite, le débogueur, ce sera vous. Mais si après 10 ans d'expérience professionnelle, vous avez recourt à un débogueur, alors je vous le dit "changé de boulot". Car après tout ce temps, vous ne connaissez toujours pas ni le langage, ni des méthodologies de développement et donc vous êtes totalement incompétent.

Aussi competent soit-on, on finit toujours par intervenir sur du code d'une telle complexite qu'un bon debogueur sera utile a un moment ou un autre, ne serait-ce que pour nous montrer que tel bout precis de code ne marche pas exactement de la maniere qu'on croyait. Vous aurez beau avoir 160 de QI, une memoire procedurale phenomenale, une grande maitrise de vos outils, une methodologie en acier trempee homologuee par tel grand gourou, il arrivera toujours un moment ou un debogueur vous permettra de voir tout de suite une anomalie que vous n'imaginiez meme pas possible.

Et vous de corriger en cinq minutes une erreur sur laquelle vous auriez perdue plusieurs heures a l'epoque ou vous vous croyiez infaillible.

Je crois sur parole les gens qui disent faire plus souvent des fprintf que du gdb, parce que pour ce qu'ils font, le fprintf leur fait gagner du temps. Je ne saurais personnellement dire si je fais plus souvent du gdb ou des affichages pour deboguer, mais il est clair qu'en general je vois tres vite laquelle des deux methodes sera la plus efficace. Dans mon cas j'ai constate que la proportion de gdb augmente, tout simplement parce que je sais de mieux en mieux l'utiliser et qu'il me permet de gagner du temps dans de plus en plus de cas de code bien complexe.

En revanche je ne crois pas qu'on puisse se passer totalement d'un debogueur sans perdre, de temps en temps, une demi-journee entiere sur un "simple petit bug".

[I_believe_in_code]

Je crois que vous n'avez pas une grande expérience dans la recherche des anomalies.

Et quelle est votre experience des debogueurs ?

Il arrive qu'une erreur est détectée à un endroit précis du programme mais que la cause est ailleurs.

Oui. Un debogueur sera extremement utile dans ce cas-la, plus que n'importe quel truffage de printf.

Le débogueur ne vous sera d'aucune utilité pour son identification.

Si.

Bon, je vais arreter de poster dans ce topic. Y'a trop d'interventions manquant d'honnetete intellectuelle, il faudrait repondre a chaque post tellement d'aneries ont ete dites...

C'est pour cela que je le "remonte" maintenant. Je n'y avais pas reagi plus tot pour eviter de m'enerver franchement.

[souviron34]

disons que je pense que ton post précédent est rempli de bon sens, mais pas celui d'avant, et qu'il me semble que nous avions répondu à peu près aux "absurdes"..

Ne JAMAIS utiliser c'est pas terrible, TOUJOURS utiliser est pas franchement mieux..

ça dépend des cas, de ce qu'on fait, de ce qu'on débuggue, de son expérience, ...

[el_slapper]

disons que je pense que ton post précédent est rempli de bon sens, mais pas celui d'avant, et qu'il me semble que nous avions répondu à peu près aux "absurdes"..

Ne JAMAIS utiliser c'est pas terrible, TOUJOURS utiliser est pas franchement mieux..

ça dépend des cas, de ce qu'on fait, de ce qu'on débuggue, de son expérience, ...

+1, mais ça dépend aussi des outils qu'on a. J'utilise très souvent le débuggueur sur VBA pour Excel, quasiment jamais sur Cobol. Essentiellement parceque le débuggueur cobol qu'on a ne correspond pas à mes besoins. Il y a sans doute d'autres raisons, par exemple le style de chose qui sont développées.

Mais, globalement, je dirais que c'est bien d'avoir les deux dans sa boite à outils. Le printf/display ET le débuggueur.

[larry57]

Personnellement, le déboggeur est très utile.
Sur as/400, il y a une commande dédiée STRDBG très facile d'utilisation.
De plus lors d'un plantâge, le système donne la ligne et on peux faire un DUMP mémoire. (facile pour trouver ce qui plante).

Larry57

[gallima]

Bonjour,
ce qui tourne autour de ce débat semble souligner l'importance du débugger.

Aspect 1.
Je suis d'avis que le debugger est un outil indispensable dès lors que le code a été écris par une autre personne (aka une autre logique que la sienne).
Les concepteurs de langages sont peut-être très forts et font des codes super sophistiqués, mais il faut préférer le standard à l'original; il faut préférer le code que l'on peut lire après 3 bières, avoir perdu son chat et sa copine et un n+1 qui vient de changer les exigences.

Souvent les codes qui ont un peu d'histoire sont loin de leur belle architecture des débuts. Ils sont durs à tracer. Seul un débugger permet d'en reprendre la logique... avant de les ré-écrire.

Avant d'être simple le code est compliqué ! Et on a rarement le temps de revenir dessus.

Aspect 2
Certains parlent aussi d'interpréteurs interactifs et disent ne pas utiliser de debugger... je trouve que l'interpréteur interactif se comporte souvent comme un debugger; pour moi c'est presque là même chose.

Aspect 3
Dans ma boite, tous nos logiciels c++ sont déployés en mode 'debug', compiler avec l'option '-g' de g++. En cas de pépin, nous reprenons l'exe déployé et nous attachons le debugger au process. Là nous sommes certains d'avoir la même chose que le client.

Aspect 4
Souvent les logs sont insuffisants. Les logs traces surtout les anomalies déjà identifié. Je ne compte plus les fois où nous avons livrés de nouveaux exe sans nouvelles fonctionnalités mais juste avec des logs en plus... jusqu'au jour où les gens capables d'interpréter certains messages sont parties. Nous avions alors un deuxième "code" (les logs) en plus du code du programme; WTF!

Soit nous sommes capable de reproduire l'environnement du client, soit nous prenons un core-dump; les logs ne me diront pas que le problème vient d'une interaction curieuse avec un composant tiers. Une fois dans le debugger je pourrais voir comment le problème peut se former et tenter de le reproduire.

Aspect 5
Les limites des débugger actuelles sont facilement atteintes; surtout dans un contexte réseau, où plusieurs serveurs communiquent. Je pense qu'il s'agit plus d'une limite technique des débugger actuelles qu'une remise en question de leurs intérêts.

Le bon debugger du future devrait être capable de simuler des envois de messages et d'instancier des machines virtuelles. Mais je ne vois pas en quoi un système permettant de faire "Pause" dans l'exécution serait une mauvaise chose. A un moment, tous système devient suffisamment compliqué pour que personne ne puisse le valider sans le stopper momentanément et en observer tout les aspects.

Ouverture
Cette problématique fait partie du grand cadre du problème de diagnostique système et n'est pas spécifique au dev. Exemple : Le médecin préfère parfois l'IRM/RADIO que d'observer attentivement le patient; idem pour le dev avec le debugger.

Cordialement,
K.

ps: Un debugger pour savoir ce qui fait déconner l'orthographe dans ma tête sa serait mieux que les logs :p La méthode global y est surement pour quelque chose... mais où.

[Ubiquité]

Perso je profite du debugger quand j'en ai un, sinon je fais très bien sans.
Je trouve ça dommage d'être dépendant du debugger, il faut être capable de debugger sans.

[arkhamon]

Bonjour à tous,

tiens ben moi aussi je vais sauter dans la mare ! Je n'utilise JAMAIS de debugger. D'ailleurs, je sais même pas comment le lancer ni l'utiliser. Petite info, j'ai débuté en Turbo Pascal sur un Logabax LX-529, et je suis actuellement en Delphi 2007. Passages divers en VB, VBA, C (sous la contrainte seulement), COBOL, FORTRAN, ADA, LISP, PROLOG, ASM... Et je peux vous dire qu'il y a une palenquée de langages ou d'EDI qui ne proposent pas de débugger. Je fais comment pour débugger ?
Si ca plante, j'utilise le Super-califragilistiquement puissant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Showmessage(machintostr(valeur à surveiller));

aussocié au non moins superhypertoppuissant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if truc = nil then showmessage('Le machin est pas affecté');

J'entends déja :

"ouais et quand t'es dans une boucle de 60000 itérations tu pose une enclume sur la touche Enter ?"

Nan. Là je passe par un super objet que je me suis fait, qui à sa création ouvre une forme contenant un edit multiligne, et à chaque chose que je veux vérifier, je fais un add(commentaire) avec éventuellement une référence d'objet (genre self.name ou autre...). Dans le destroy de l'objet, il balance tout son contenu dans un fichier texte pour lecture future... De mon temps, on appelait ça un trace log... Redoutable ! Ca a l'air archaïque, mais ca sert aussi à une chose : tracer les transactions faites par le soft...
Je crois qu'en java on appelle ça... LA CONSOLE !

J'utilise aussi le TStatusBar en bas de la fenêtre comme le fait Excel, ça rend pas mal service aussi.

Je peux être désagréable ? Allez tant pis je le fais quand même : plutôt que de regarder une trace de debugger avec des stack report, commencez par initialiser vos pointeurs. Vous verrez, ça ira tout de suite mieux.

D'ailleurs, si on respectait un peu plus la modularité, l'encapsulation et la visibilité, je pense qu'on aurait nettement moins besoin de débugger. Mais je suis le premier à pas respecter tout alors...

[zaventem]

Je n'utilise JAMAIS de debugger. D'ailleurs, je sais même pas comment le lancer ni l'utiliser.

Autant je peux comprendre qu'on n'utilise pas de debugger par choix au vu d'une situation données, ne pas l'utiliser par ignorance (et de plus le revendiquer) est pour moi ridicule.

[arkhamon]

Autant je peux comprendre qu'on n'utilise pas de debugger par choix au vu d'une situation données, ne pas l'utiliser par ignorance (et de plus le revendiquer) est pour moi ridicule.

Rhâââââ ces gens qui ne savent pas lire...
Je n'ai pas dit que je ne l'utilisais pas PARCE que je ne savais pas comment le lancer, j'ai dit que je ne l'utilisais pas, et QU'EN PLUS je ne savais pas comment le lancer...
Ecoute au lieu d'entendre jeune paddawan, ça t'évitera de traiter de ridicule quelqu'un qui ne l'est peut être pas plus que toi...

[zaventem]

Je maintiens ce que je dis.

Ne pas vouloir se donner la peine de tester et de comprendre le fonctionnement d'une catégorie d'outils qui ont ait leurs preuves est ridicule.

Je ne dis pas que le debugger est une meilleure solution que les logs, je ne dis pas non plus que les logs sont une meilleure solution que le debugger; juste qu'un professionnel (ce que tu es censé être) se doit de connaitre les différents outils à disposition et les utiliser à bon escient.

[Marc3001]

Rhâââââ ces gens qui ne savent pas lire...
Je n'ai pas dit que je ne l'utilisais pas PARCE que je ne savais pas comment le lancer, j'ai dit que je ne l'utilisais pas, et QU'EN PLUS je ne savais pas comment le lancer...
Ecoute au lieu d'entendre jeune paddawan, ça t'évitera de traiter de ridicule quelqu'un qui ne l'est peut être pas plus que toi...

Tu sais pas le lancer donc y'a des chances pour que tu saches pas non plus l'utiliser.... La réflexion de zaventem se tient....

[arkhamon]

Je maintiens ce que je dis.

Ne pas vouloir se donner la peine de tester et de comprendre le fonctionnement d'une catégorie d'outils qui ont ait leurs preuves est ridicule.

Je ne dis pas que le debugger est une meilleure solution que les logs, je ne dis pas non plus que les logs sont une meilleure solution que le debugger; juste qu'un professionnel (ce que tu es censé être) se doit de connaitre les différents outils à disposition et les utiliser à bon escient.

Ca y est vous avez réussi à m'énerver...
A mon humble avis, un bug est avant tout une erreur de transcodage. Je m'explique... Un bug c'est une réaction différente par le progarmme produit de ce qui a été prévu (donc analysé). Donc par extension, si un programmeur respectait scrupuleusement 2 choses :

• coder exactement ce que l'analyste lui a communiqué
• respecter les règles de l'art

Ben... y aurait pas de bugs !
Remarquez au passage que je ne parle que de bug, et pas d'erreur de conception. Les deux sont totalement différents.
Si un soft plante sur un fichier inexistant (je parle pas de message d'alerte, je parle d'un runtime error), c'est que la programmation ne s'est pas faite suivant les règles de l'art, puisque le programme devrait s'assurer avant d'ouvrir le fichier, qu'il lui est bien possible de le faire sans crasher. Ou alors il tente de le faire et intercepte l'exception. Maintenant, on peut aussi se pencher sur le code appelant qui transmet un nom de fichier incorrect... D'où la nécessaire modularité du code...
Si dans du code je trouve :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

a := b/c;

et que je ne vois pas la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if c <> 0 then...

alors je dis que le programmeur n'a pas fait les choses correctement. Pareil pour un pointeur non assigné.

Ensuite, dans les règles de l'art, il y a des notions comme l'encapsulation, la visibilité, la modularité, l'unicité qui font qu'une routine est là pour faire une chose et une seule, en fonction d'entrées identifiées et valides, et produit à la fin un résultat identifié et valide. Et si cette routine assure bien son rôle de ne fournir qu'un résultat approuvé, alors elle devient autonome et fiable... Si ça plante, on sait où c'est. Je vous rassure tout de suite : je donne des grandes leçons gratos, mais je fais l'inverse quand c'est moi qui développe... pour mon plaisir perso ! mes softs je les fais pour moi si ça plante tant pis pour moi. Mais dans un cadre professionnel, ça ne devrait pas être toléré.

Quant à l'utilisation d'un debugger, à mon avis, si on respecte les principes ennoncés plus haut, son utilité ou du moins sa nécessité devient moins criante.
Après, et je le reconnais humblement, certains outils de développement modernes ont mis en place des hérésies comme le garbage collector parce que ça fasait chier les développeurs de désallouer leurs pointeurs eux-mêmes. SOLUTION DE FACILITE !

Et au risque de passer pour un vieux râleur qui se répête : quand j'entends un mec me dire que son serveur est à genoux parce qu'il y a des "fuites mémoire", ça me pousse à... et surtout

Et pour finir, si je n'utilise pas de debugger, c'est parce que je n'en ai pas le besoin ni l'utilité pour l'instant. Ca ne veut pas dire que je ne suis pas professionnel, ni que je suis idiot, ni incompétent. J'ai juste décidé c'est tout.
C'est comme les gens qui ne prennent pas leur voiture pour faire les 500 m pour aller à la boulangerie. Ca peut paraître con, mais c'est comme ça.

P.S. : mes provocations marchent bien. Je rassure tout le monde, je sais comment lancer le debugger de Delphi, je sais même faire une exécution instruction par instruction, mettre des points d'arrêt, et surveiller des variables... Mais je sais aussi faire sans, et le jour où je me retrouve sur un EDI qui n'offre pas tout ça, je ne suis pas paumé. Certains appellent ça "ringardise", moi je préfère "savoir faire"...

[souviron34]

En dehors de ta provocation (et de ta conclusion avec laquelle je suis d'accord), je me permet de commenter sur :

Passages divers en VB, VBA, C (sous la contrainte seulement), COBOL, FORTRAN, ADA, LISP, PROLOG, ASM... Et je peux vous dire qu'il y a une palenquée de langages ou d'EDI qui ne proposent pas de débugger. Je fais comment pour débugger ?

en utilisant emacs (ou Xemacs), tu as quasiment tous les langages que tu veux (d'ailleurs il est codé en Lisp), avec debugger intégré

[arkhamon]

en utilisant emacs (ou Xemacs), tu as quasiment tous les langages que tu veux (d'ailleurs il est codé en Lisp), avec debugger intégré

Houla... C'est la vision des 5000 çà !
"Je vous parle d'un temps que les moins de 20 ans ne peuvent pas connaîaîaîaître..."
Plus exactement de 1985 et du mini-système TI 990/4 royalement doté de 384 Ko de RAM, et deux disques MARK50 (les machines qui ressemblaient à des machines à laver), d'un lecteur de disquettes 8" (les mêmes que les 5"1/4 mais en plus grand et moins de capacité) et d'un COBOL ANS74 d'une pureté suprême, la seule forme de graphisme possible à l'époque étant limité à la capacité de jouer avec les signes "+", "-" et "*" pour faire des cadres, et un compilateur qui stoppait la compil après 10 erreurs en balaçant le laconique mais néanmoins insultant "Fatal error or null program...".
Alors pour le debugger en temps réel...

[Guilp]

P.S. : mes provocations marchent bien. Je rassure tout le monde, je sais comment lancer le debugger de Delphi, je sais même faire une exécution instruction par instruction, mettre des points d'arrêt, et surveiller des variables... Mais je sais aussi faire sans, et le jour où je me retrouve sur un EDI qui n'offre pas tout ça, je ne suis pas paumé. Certains appellent ça "ringardise", moi je préfère "savoir faire"...

C'est en effet vraiment de la provocation...
Tu dis :
1) tu n'utilise JAMAIS de debugger
2) les debuggers, c'est pour ceux qui savent pas programmer
3) tu te lances même une auto-pique à la place "des autres" comme quoi ces autres pensent que tu es ringard
4) tu reconnais que tu as déjà utilisé un debugger, mais qu'en fait l'important c'est de savoir programmer...

Donc oui, c'est vraiment de la grosse grosse provocation (pour ne pas dire du troll)... Quand tu aurais tout simplement pu dire "le debugger, c'est bien, ça facilite la tâche, mais il ne faut pas se reposer uniquement dessus, il faut en effet savoir programmer dans les règles de l'art pour l'éviter et surtout pouvoir s'en passer dans les cas où il n'y en a pas."

Le côté obscur de la force est une tentation trop grande pour toi, chevalier Jedi...

[Marc3001]

A mon humble avis, un bug est avant tout une erreur de transcodage. Je m'explique... Un bug c'est une réaction différente par le progarmme produit de ce qui a été prévu (donc analysé). Donc par extension, si un programmeur respectait scrupuleusement 2 choses :

coder exactement ce que l'analyste lui a communiqué
respecter les règles de l'art

Ben... y aurait pas de bugs !

Entre la spec pondue par l'analyste et le code produit par le développeur y'a pas que de la traduction... Y'a un peu de reflexion, et de choix techniques effectués par le développeur.
Si le développeur n'avait qu'à traduire une spec d'analyste, y'aurait plus de développeur et ça serait automatique.

Du coup dans la reflexion et l'implémentation du développeur, il peux y avoir des erreurs de saisie, des soucis techniques qui sont introduits lors de la phase de codage même si le code correspond parfaitement à l'analyse.

Sans parler des erreurs qui peuvent être faîtes aussi dans l'analyse....

[souviron34]

Houla... C'est la vision des 5000 çà !
"Je vous parle d'un temps que les moins de 20 ans ne peuvent pas connaîaîaîaître..."

Dernière utilisation industrielle en date sur un projet sur lequel j'ai été : 2009...

Par moi: aujourd'hui.

Je ne comprend pas bien ce que tu veux dire..

Et tu peux (sur unixoides) utiliser ddd..

Mais pour ce qui est de comprendre/compiler/debugger un très grand nombre de langages avec 1 seul outil aujourd'hui je ne connais rien d'autre que emacs..

[arkhamon]

Je ne comprend pas bien ce que tu veux dire.

Ce que je veux dire, c'est qu'à l'époque sur le vieux TI990, y avait pas de debugger COBOL, donc le debuggage on le faisait à la main...
Et ensuite j'ai pris l'habitude de continuer à faire à la main. Du coup je n'utilise presque jamais le debugger (Delphi) car en général j'arrive à m'en sortir sans...

[I_believe_in_code]

Je suppose que tout le monde arrive a s'en sortir sans.