Perso, j'utilise le déboggueur pour Delphi et pas pour Java.
Je pense en fait que le déboggueur intégré est essentiel dans un langage évenementiel, alors qu'il est plus pratique dans un cadre d'application serveur ou console de débogguer à la volée.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Perso, j'utilise le déboggueur pour Delphi et pas pour Java.
Je pense en fait que le déboggueur intégré est essentiel dans un langage évenementiel, alors qu'il est plus pratique dans un cadre d'application serveur ou console de débogguer à la volée.
perso j'utilise pas de debugger autre que printf, la raison est simple je suis un grop paresseux et je code avec vi/gcc quand j'ai fini j'execute donc j'ai la paresse de lancer encore gdb je prefere lire un fichier log ou juste le retour des printfs. sans avoir a toucher au clavier pour voir le break point suivant.
juste une question de paresse (en plus il faut apprendre a l'utiliser le debugger).
vous me direz je suis pas si paresseux que ca si j'insert des printf que je devrait virer plus tard...
Cela dépend du projet. En Visual C++, ou C#, il serait improductif de s'en passer.
Pour du code embarqué (processeur PIC18), j'utilise deux techniques:
allumer un bit selon condition, et pour du code plus élaboré, je me suis fait un include de compatibilité décrivant la mémoire et les I/O dans Code::blocs.
Là, je peux me faire "avoir" avec des int de 32 bits (contre 16 pour PIC)...
Par contre, on peut tester à fond ses fonctions.
De manière générale, si on produit du code embarqué, on réfléchit 4 x plus avant de lancer un chargement.
Bah taper sous vim en SSH c'est un peu pareil non ?Envoyé par ymasur
C'est d'ailleurs pour ça que je dis que lorsque je n'ai pas de compilateur je suis obligé de réfléchir plus et de bien relire mon code avant de tester. (cf un de mes premiers post ici)
La vérité...
Oubliez l'hypothèse que ces "esprits supérieurs" aient plus de "stack space"... ils ont, au mieux, une "bibliothèque" d'abstractions très étendue, qui leur permet d'utiliser leur "stack space" de façon plus efficace.
(N.B. on parle de mémoire de travail et de mémoire à long terme, et non de "stack space" et "bibliothèque"...)
Je crois plus vraisemblabe que ce sont des programmeurs très expérimentés et qu'ils font tout simplement ce qu'ils ont pris l'habitude de faire il y a bien longtemps.
J'ai appris à programmer à une époque où les débogueurs n'existaient pas, et un petit "print" de temps en temps aidait à comprendre comment les choses se passaient.
Aujourd'hui, j'utilise volontiers du MsgBox même si je dois reconnaître que le débogueur est plus efficace, puisqu'il permet de voir l'état de toutes les variable et d'identifier plus rapidement le problème... Mais j'ai plus le réflexe MsgBox que débogueur... c'est comme ça.
piqure de rappel
Bonsoir,
S'il y a bien une personne qu'on a oublié, c'est l'analyste-programmeur.
Il n'existe plus ce métier et depuis longtemps.
Pourtant, c'était un très beau métier. Parce que c'était un analyste mais aussi un programmeur (sans nul doute).
Et par analogie, le "statisticien" est à l'analyse des statistiques ce que l'analyste-programmeur est à l'analyse des ...programmes.
L'époque de l'analyste-programmeur est révolue à cause du déboggueur automatique ? cette vérité n'en est pas une.
Un déboggueur qui fait : "votre erreur de logique se trouve là _" (en clignotant), cela n'existe pas.
Et soyez rassuré, des gens qui disent "ah mais l'erreur elle est là, il y a un + à la place d'un -", il y en a encore.
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
aussocié au non moins superhypertoppuissant
Code : Sélectionner tout - Visualiser dans une fenêtre à part Showmessage(machintostr(valeur à surveiller));
J'entends déja :
Code : Sélectionner tout - Visualiser dans une fenêtre à part if truc = nil then showmessage('Le machin est pas affecté');
"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...
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...
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 :
Ben... y aurait pas de bugs !
- coder exactement ce que l'analyste lui a communiqué
- respecter les règles de l'art
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 :
et que je ne vois pas la ligne
Code : Sélectionner tout - Visualiser dans une fenêtre à part a := b/c;
alors je dis que le programmeur n'a pas fait les choses correctement. Pareil pour un pointeur non assigné.
Code : Sélectionner tout - Visualiser dans une fenêtre à part if c <> 0 then...
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"...
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....
En dehors de ta provocation (et de ta conclusion avec laquelle je suis d'accord), je me permet de commenter sur :
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 çà !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é
"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...
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..
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...
Perso je me suis rendu compte que mon IDE avec un debuggeur plus d'un an après son utilisation.
On m'a toujours appris, pour le debuguage, de positionner des balises (print, echo, messagebox etc...) pour trouver la tranche où le code déconne et agir en conséquence.
Mais le debogueur qui permet de connaître exactement les données, ça c'est top.
Il faut savoir que l'orsque l'on développe un langage on ce retrouve à programmer avec des notions de récursives mutuelles (le fameux recursive descent parser) des arbres de compilation (Abstract Syntax Tree), en objet, des visiteurs à couper au couteau... bref, des structures qui rendent quasi impossible le debuggage.
Effectivement des traces bien placés et bien conçus et surtout un bonne dose d'intuition (qui tiens parfois plus de l'hésothérisme que de la logique mathémarique que nous connaissons) sont souvent les seuls outils qui soit pratiquable.
Parce qu'un breakpoint dans une pile d'execution d'une centaine d'étages, ça fait relativement mal à la tête, et n'aide en rien à comprendre le problème.
Retrouvez tous mes tutoriels : http://caron-yann.developpez.com/
Et mon projet en cours : Algoid - programming language
N'oubliez pas de consulter les FAQ Java (http://java.developpez.com/faq/) et les cours et tutoriels Java (http://java.developpez.com/cours/)
Je connais l'hédonisme, l'ésotérisme, le thésaurisme, mais pas l'hésothérisme
Discussion intéressante.
J'utilise un débogueur interactif depuis toujours, et je programmerai difficilement sans.
par contre, j'ai rencontré un autre de ces gourous de la programmation. Il est l'auteur unique d'un énorme logiciel de calcul numérique. Nous avons travaillé ensemble sur quelques projets. je l'ai donc vu travailler dans son quotidien. J'ai été très surpris de sa pratique de la programmation totalement à l'opposé de la mienne : il édite ses sources avec vi (éditeur de texte en ligne de commande de Linux) et ne se sert pas de débogeur.
Autre différence d'avec moi : il n'a pas BESOIN d'un débogueur.
La seule explication que je vois est donc une plus grande capacité à se représenter mentalement la "géographie" de son projet.
Répondre avec citation
Partager