Comment déboguer sans IDE? [fermé]

Chaque fois que je cherche un IDE (actuellement, je bricole avec Go), je trouve un fil plein de gens qui recommandent Vi, Emacs, Notepad ++, etc.

Je n'ai jamais fait de développement en dehors d'un IDE; Je suppose que j'ai été gâté. Comment déboguer sans IDE? Êtes-vous limité à la journalisation?

En utilisant un débogueur. Dans la plupart des cas, c’est aussi ce que fait une IDE en coulisse: elle enveloppe simplement l’expérience dans une interface graphique.

Sous Unix, l’un des débogueurs les plus couramment utilisés est GNU gdb, qui a largement supplanté les débogueurs Unix précédents tels que dbx.

Pour avoir une idée de ce à quoi ressemble le débogage depuis la ligne de commande, consultez le manuel de gdb .

Comme dans d’autres domaines, l’utilisation d’un débogueur à partir de la ligne de commande nécessite l’apprentissage d’une syntaxe et d’un ensemble de commandes, mais apporte beaucoup de souplesse et de possibilité de script. D'un autre côté, si vous êtes déjà à l'aise avec un éditeur tel que vim ou emacs, il est possible que votre éditeur favori dispose d'un plug-in pour votre débogueur préféré.

J'ai utilisé un débogueur pendant plusieurs années alors que j'écrivais des pilotes graphiques. J'avais un deuxième ordinateur qui exécutait le débogueur par rapport au premier (car l'écran de l'ordinateur principal ne fonctionnait pas lorsque le pilote graphique était endommagé). Il était essentiel de pouvoir arrêter le code et aller au point de suspendre le matériel pour que je sache ce qui se passait.

Pour les problèmes purement logiciels, je trouve que penser au problème et tester le système pour en savoir plus sur le problème est beaucoup plus utile que de parcourir le code ligne par ligne. Avec les instructions d'impression, j'ai une liste de tout ce qui s'est passé sur la ligne de commande ou le fichier journal que je peux regarder et reconstruire ce qui s'est passé, en effectuant des va-et-vient plus facilement que je n'aurais jamais pu le faire avec un débogueur.

Les bugs les plus difficiles sont généralement résolus en comprenant le problème loin de l’ordinateur. Parfois, avec un morceau de papier ou un tableau blanc, et parfois, la réponse se révèle pendant que je fais autre chose. Les bugs les plus délicats sont résolus en regardant attentivement le code, comme jouer à Where's Waldo. Tout le reste semble plus facile avec les instructions d'impression ou les instructions de journalisation.

Différentes personnes ont différents styles et différents styles conviennent mieux à différentes tâches. Les instructions à imprimer ne sont pas nécessairement une étape d'un débogueur. Selon ce que vous faites, ils peuvent même être meilleurs. Surtout dans une langue qui n'a pas de débogueur natif (est-ce que Go?).

Certaines personnes utilisent gdb sur la ligne de commande ou un plugin . Il existe également des interfaces utilisateur autonomes à gdb, comme DDD . Selon votre langue, il existe des interfaces utilisateur graphiques spécifiques au langage pour le débogueur, telles que Winpdb pour python ou jswat pour java. Parce que ces projets se concentrent uniquement sur le débogage, ils sont souvent supérieurs aux débogueurs intégrés.

L'autre petit secret sur les IDE vaut la peine de spécifier un éditeur personnalisé. Vous pouvez donc utiliser des parties de l'EDI pour certaines tâches, mais utilisez un éditeur correct pour l'édition. Il n'est pas rare de lancer un IDE pour utiliser son débogueur, surtout si c'est ce que tous vos collègues utilisent.

Certaines langues proposent un REPL, c’est-à-dire que vous pouvez écrire et exécuter du code ligne par ligne au fur et à mesure de son écriture, ce qui peut constituer une première étape dans la vérification d’un morceau de code. Beaucoup d'entre eux offrent également des installations de débogage. GHC pour Haskell est livré avec GHCi qui peut être utilisé pour déboguer de manière interactive un programme dans la ligne de commande, comme le ferait un IDE.

Je ne comprends pas pourquoi il y a une aversion pour le débogage avec l'utilisation d'instructions printf. Il fut un temps où la recompilation et la liaison d'un programme prenaient trop de temps, mais aujourd'hui, cela ne prend que quelques secondes. Je trouve très facile de déboguer en utilisant cout, printf, qDebug (), etc. Les instructions Printf vous donnent un historique d'exécution de tout ce que le programme a fait, que vous pouvez analyser après coup, alors que l'exécution dans le débogueur vous oblige à vous souvenir manuellement du flux du programme en cours d'exécution. Avec printf, vous pouvez convertir la valeur des variables en unités spécifiques, les afficher en hexa, décimal, peu importe. Les instructions printf peuvent lister les noms des routines et des variables, ainsi que les numéros de ligne. Vous ne pouvez répertorier que certains éléments de tableau en fonction d'autres variables. Vous pouvez suivre des indirections. Vous pouvez contrôler la sortie très facilement, insérez des compteurs, imprimez seulement certaines heures par une boucle, ajoutez et supprimez des instructions d'impression à mesure que vous déboguez, disposez de niveaux de sortie de débogage différents, écrivez dans des fichiers, etc. Il est beaucoup plus facile de voir l'historique de votre programme écrit dans un fichier que de le faire. essayez de vous souvenir manuellement de tous les endroits que vous avez traversés, et peut-être devez écrire le contenu des variables au fil du temps, afin de découvrir ce que le programme a fait. Et enfin, avec les instructions printf, vous pouvez les laisser en permanence, pour les activer et les désactiver, pour un débogage ultérieur. C est beaucoup plus facile de voir l’historique de votre programme écrit dans un fichier que d’essayer de vous rappeler manuellement tous les endroits que vous avez traversés, et peut-être d’écrire le contenu des variables au fur et à mesure de leur évolution dans le temps, afin de découvrir le programme a fait. Et enfin, avec les instructions printf, vous pouvez les laisser en permanence, pour les activer et les désactiver, pour un débogage ultérieur. C est beaucoup plus facile de voir l’historique de votre programme écrit dans un fichier que d’essayer de vous rappeler manuellement tous les endroits que vous avez traversés, et peut-être d’écrire le contenu des variables au fur et à mesure de leur évolution dans le temps, afin de découvrir le programme a fait. Et enfin, avec les instructions printf, vous pouvez les laisser en permanence, pour les activer et les désactiver, pour un débogage ultérieur.

jimwise a très bien répondu à la question, mais j’ai pensé que je devrais ajouter que, si vous choisissez de travailler sans IDE complet, le débogueur en ligne de commande fourni par Microsoft pour Windows s’appelle CDB . CDB est fourni avec plusieurs autres outils, notamment WinDBG, l’équivalent de l’interface graphique, lorsque vous téléchargez le kit de développement logiciel (SDK) de Windows.

Je n'utilise généralement pas de débogueur, peut-être une fois toutes les deux semaines, mais ce n'est pas la première chose à laquelle je vais.

L'outil le plus important de mon travail est tellement omniprésent que j'ai failli oublier de le mentionner: les traces de pile. Plus de 90% des problèmes que je rencontre peuvent être résolus en examinant une trace de pile. Selon votre langue, cet outil n’est pas toujours très utile, mais s’ils sont bien implémentés par une langue, ils peuvent vous faire gagner un temps fou.

La deuxième manière la plus courante de détecter des problèmes simples est probablement le code que je viens de modifier. Je fais des tests unitaires assez souvent, donc je sais généralement ce que je viens de casser.

Pour un développement et un débogage plus complexes, je pourrais ajouter des instructions de journal de niveau de débogage ou de trace. Je considère les problèmes de développement comme un bon guide pour m'aider à placer les informations de trace de production / de journalisation de débogage, ce qui me conduit à:

Vous n'avez pas toujours un débogueur à portée de main. En production, il peut être impossible d’exécuter un débogueur (Heck, il est également impossible d’accéder aux machines de production, à l’exception des journaux, en fonction de la sécurité de votre entreprise). Il y a aussi des langages où connecter un débogueur prend trop de temps ou peut-être qu'il n'y a tout simplement pas de bons débogueurs disponibles.

Si vous avez toujours codé à l'aide de la logique et de la journalisation au niveau de débogage / trace, vous pouvez simplement examiner vos excellentes instructions de journal (éventuellement augmenter le niveau de journalisation) pour résoudre le problème sans même accéder au matériel.

Bien que je pense que les débogueurs sont un outil puissant, ne les laissez pas être le seul outil de votre boîte à outils!

Il n'y a aucune raison pour que vous ne puissiez pas utiliser le débogueur dans un IDE avec un éditeur de texte autonome. J'utilisais auparavant! Zap pour éditer, JBuilder pour déboguer sur une autre machine et un serveur de fichiers au sous-sol. Les débogueurs étaient traditionnellement des programmes autonomes sans glisser d'un IDE, et cela fonctionne aussi.

Il convient de noter que des tests complets remplacent le débogage. Il est utile de considérer un bogue signalé comme un bogue dans vos tests plutôt que dans votre code.

Il y a aussi printf. Il peut être utile de créer une grande quantité de "journalisation" et d'effectuer une recherche à travers celle-ci, plutôt que de s'arrêter pour chaque ligne. Je trouve particulièrement utile si vous pouvez modifier des classes de bibliothèque que vous ne pourriez pas modifier en production, par exemple en utilisant -Xbootclasspath/p:pour pirater des classes de bibliothèque Java.

Convenez que le meilleur des problèmes peut être résolu loin de l'ordinateur avec un stylo et du papier ou simplement en réfléchissant au problème. Ceci est plus utile que d’utiliser des débogueurs en direct. Cela corrige souvent votre processus de réflexion.

Vous pouvez utiliser pudb qui est une console basée sur une interface utilisateur simple. Vous pouvez choisir votre débogueur préféré, tel que pdb ou ipdb, si vous souhaitez entrer un REPL et l'examiner plus en détail.

Consultez également le wiki de PythonDebuggingTools pour une collection plus complète d'outils disponibles.