Discussion :

[yann2]

C'est un peu prétentieux comme point de vue, non? ^^

Ce n'est pas un point de vue, c'est un constat. Enfin je ne sais pas trop quelle partie du texte est visée. Certains n'ont pas appris à se servir du débogueur (c'est ça qui te choque ?). Si ils n'ont pas appris et qu'ils n'ont pas essayer par eux même, il faut bien leur montrer que ça existe quand même, non ? Enfin, je vois rien de choquant.

Si c'est l'autre partie de la citation : le printf ne te permet pas de faire tout ce que peut faire un débogueur. Donc, non, pour moi le résultat n'est pas le même du tout. Je disais juste, "au pire" : le débogueur permet de faire ce que fait le printf (sauf cas exceptionnels). Donc pourquoi désapprouver l'utilisation du débogueur et clamer que si on en utilise un c'est qu'on fait du code de mer pas joli ou qu'on ne fait pas assez de tests ? (lire tout le débat). Mais bon, je n'ai qu'un bac +3

[Haseo86]

Ce n'est pas un point de vue, c'est un constat. Enfin je ne sais pas trop quelle partie du texte est visée. Certains n'ont pas appris à se servir du débogueur (c'est ça qui te choque ?). Si ils n'ont pas appris et qu'ils n'ont pas essayer par eux même, il faut bien leur montrer que ça existe quand même, non ? Enfin, je vois rien de choquant.

Si c'est l'autre partie de la citation : le printf ne te permet pas de faire tout ce que peut faire un débogueur. Donc, non, pour moi le résultat n'est pas le même du tout. Je disais juste, "au pire" : le débogueur permet de faire ce que fait le printf (sauf cas exceptionnels). Donc pourquoi désapprouver l'utilisation du débogueur et clamer que si on en utilise un c'est qu'on fait du code de mer pas joli ou qu'on ne fait pas assez de tests ? (lire tout le débat). Mais bon, je n'ai qu'un bac +3

Non non, je ne dis absolument pas que je désapprouve l'utilisation d'un déboggeur ni que ça donne des mauvais résultats, au contraire, je dis que c'est une question d'habitude de travail, rien de plus.

Après ma remarque portait sur la stigmatisation des "fraichement diplomés", sous entendant que si on n'utilise pas le déboggeur, c'est parce qu'on est mal ou pas assez formé.

Sinon, pour ma part je ne vois aucune raison à cataloguer les utilisateurs ou non de ces outils : si on aime ça et qu'on y trouve des avantages, tant mieux, si on préfère faire à la main, et qu'on s'en sort aussi bien, tant mieux aussi.

[souviron34]

comme j'ai dit plus haut, cela n'a à mon avis rien à voir avec le niveau d'études, mais tout simplement avec l'expérience..

Il y a des cas où se servir d'un débugeur est pratique et rapide, il y a des cas où se servir d'un printf est pratique et rapide..

Il se trouve que quelqu'un qui a une très forte habitude de coder - et qui n'a pas suivi de "formation spéciale en informatique", comme la plupart des développeurs cités dans le PO ou comme tous les gens des domaines scientifiques en général (et je dois vous rappeller qu'ils constituent néanmoins une énorme base de développeurs, entre mathématiciiens, physiciens, et autres chimistes (que ce soit les bibliothèques d'imagerie comme tiff, jpeg, MPEG, et autres, les biblothèques HTTP ou celles qui sont à la base du Web comme la définition de HTML, les bibliothèques de maths, la plupart des bibliothèques de traitement d'images et de "moteurs physiques", et autres bibliothèques de texturage et vision 3D, ....), choisira le meilleur outil en fonction du problème..

Et il n'est pas rare que le meilleur outil soit le printf...

C'est tout..


Pour la plupart d'entre vous, ayant suivi une formation spécifique, et ayant programmé sur Windows, vous êtes habitué à avoir un débuggeur IDE et ne pensez le développement qu'à travers ça..

Mais par exemple moi, physicien à l'origine, et n'ayant jamais suivi de cours d'info, ce n'est qu'un outil, que j'utilise quand j'ai réellement un problème délicat (du style je cherche l'endroit où ça crashe dans un core-dump). En général ensuite , dès que l'endroit est localisé, une lecture attentive et un printf judicieusement placé sera plus rapide qu'un débuggeur (surtout si il y a plusieurs processus détachés en //)...

Il n'y a donc strictement rien d'étonnant, bien que vraisemblablement ils aient forcé la dose lors de leurs réponses, à ce que ces développeurs n'en utilisent pas...

Je crois qu'ils ont forcé le trait en disant "jamais", mais il est exact que la proportion des cas où je l'utilise est infîme par rapport à la proportion des cas où j'utilise un printf, et on ne m'a jugé lent, bien au contraire, dans ma programmation et mon débogage....

Il n'y a donc pas de parti à prendre , ni de jugement à avoir.. Tout est une question d'habitude, et les 2 habitudes se valent...

Simplement le fait de dire "pouah ne pas utiliser de debuggeur c'est le Mal" part d'une sous-estimation profonde de la notion de "développeur"...

[yann2]

Non non, je ne dis absolument pas que je désapprouve l'utilisation d'un déboggeur ni que ça donne des mauvais résultats, au contraire, je dis que c'est une question d'habitude de travail, rien de plus.

Après ma remarque portait sur la stigmatisation des "fraichement diplomés", sous entendant que si on n'utilise pas le déboggeur, c'est parce qu'on est mal ou pas assez formé.

Sinon, pour ma part je ne vois aucune raison à cataloguer les utilisateurs ou non de ces outils : si on aime ça et qu'on y trouve des avantages, tant mieux, si on préfère faire à la main, et qu'on s'en sort aussi bien, tant mieux aussi.

Ah ok. Bah c'est ma propre expérience. Moi même j'ai découvert les débogueurs lors de mon premier stage.

Sinon, non, bien entendu, la non utilisation d'un débogueur n'est pas uniquement dû a un manque de formation. Pour ma part je travaille avec un IDE (comme le dit souviron). Si demain on me demande de travailler avec un outil qui n'intègre pas de débogueur je serai incapable d'utiliser le débogueur en ligne de commande et donc je mettrai des printf.

En fait mon intervention faisait référence à certains messages où il était dit que le débogueur est inutile si tu "travailles bien". Ce que je trouve un tantinet utopique.

@souviron : je procède un peu comme toi (en fait je pense qu'on doit être pas mal dans ce cas) :
Lors d'un bug :
1 - reproduire l'anomalie
2 - Si c'est possible écrire un test qui reproduit l'anomalie
3 - Identifier, dans le code, où se déclenche l'anomalie (donc là on lit le code, si on arrive directe à trouver le bug : great !)
4 - Printf ou point d'arrêt.

Et oui, je suis d'accord, il n'est pas rare que l'outil le plus simple soit printf mais, encore une fois, le printf c'est comme un débogueur moins évolué. Ou alors il faut m'expliquer ce que le printf a de plus (hormis la simplicité d'utilisation dans certains cas) ?

[el_slapper]

En fait, je dirais que la représentation de la situation est différente. Le déboggueur fait du pas à pas, permet de voir le bug en direct, là ou le printf donne une vision globale du problème. Suivant la manière dont fonctionne votre cerveau.....

Au final, c'est surtout une question d'habitude(et d'outils, mais ça, tout le monde en a convenu).

[B.AF]

Moi j'utilise plus des test unitaires que le debugger, ça me permet d'avoir un output et de comprendre.

Pour le reste, comme je développe rarement des sujets que je ne connais pas, j'ai tendance à dire qu'en lisant mon code, je vois ce qui manque, donc le besoin de faire des itérations en mode debug est pas nécessairement présent.

Les seuls fois où le debug est utile c'est souvent pour comprendre les pb de framework tiers.

Mais entre passer 35 fois le debug et écrire un test clean, au moins le second je le ré-utilise quand je veux. Et puis le debug, c'est bien en mono thread client serveur, sur des archis un peu évoluées, ça devient plus pénalisant qu'autre chose.

Mais bon, je comprends pas grand chose non plus

[TropMDR]

Moi j'utilise plus des test unitaires que le debugger, ça me permet d'avoir un output et de comprendre.

Euh, un debuger, c'est "j'ai un bug, je dois trouver d'où il vient exactement, pour le résoudre", alors qu'un test unitaire c'est "j'ai un programme, est ce qu'il a des bugs ?". Donc les deux ne sont pas interchangeable, ils sont complémentaire. Typiquement tu commences par des tests unitaires, et quand ils t'ont trouvé un bug, tu cherches son origine grâce à un debuger.

[B.AF]

[QUOTE=B.AF;5749099][HORS SUJET]
Ca me gonfle ce truc de pouces, s'il faut se contenter de dire ce qui plait; autant dire qu'on va en dire des conneries..
[/HORS SUJET]

Je dis que DANS MON CAS soit une particularité, si le test unitaire est exhaustif il est très rare que j'ai recours au debug en particulier parce que sur ce que je fais la valeur du debug est moyenne, due à la complexité.

Il faut lire avant de cliquer ou de répondre.
Il faut lire le message de souviron avant de cliquer ou de répondre si tu as moins de 35 ans.

L'informatique n'est pas l'homogénéité théorique vendue sur les bancs des écoles d'informatique. Il n'y a pas qu'Eclipse et Visual Studio, il n'y a pas que des VM partout et il n'y a pas que des architectures triviales avec des SGBD.

[Luckyluke34]

Euh, un debuger, c'est "j'ai un bug, je dois trouver d'où il vient exactement, pour le résoudre", alors qu'un test unitaire c'est "j'ai un programme, est ce qu'il a des bugs ?".

En TDD, c'est l'inverse, on écrit d'abord le test passant de la fonctionnalité avant de coder la fonctionnalité elle-même.
Avoir un test unitaire atomique et focalisé sur une seule responsabilité limite énormément le recours au debugger puisqu'on travaille dans un petit champ opératoire isolé où chaque erreur constatée lors du passage du test a vraiment du sens. En d'autres termes : si un test vraiment unitaire lève une exception, on n'a pas besoin de remonter une pile d'appels immense pour voir d'où ça vient donc plus facile à résoudre. Et lorsque l'assertion d'un test unitaire pète, le framework de test nous indique la valeur qui était attendue et la valeur réelle, ce qui suffit souvent à repérer ce qu'il faut changer.

C'est une philosophie différente, on construit son code par cycles d'essai/erreur successifs plutôt que de tout coder d'entrée et ensuite faire une introspection profonde dans les entrailles du code pour débugger. Quand je fais du TDD je recours très peu au debugger, sur ce point je rejoins BAF.

[B.AF]

Merci. Quelqu'un qui me comprend.....;

[el_slapper]

En même temps, le TDD ne permet pas forcément d'avoir une vision globale d'un projet gigantesque. Et le cas bizarre que l'on ne sait pas prévoir tant qu'il ne nous est pas tombé sur le râble, c'est un classique.(qu'est-ce que je fais si mon client décède entre le moment ou j'ouvre la procédure et le moment ou les mouvements comptables sont faits???). Même si évidemment il limite fortement le recours au débugger ou aux printf, je ne peux le concevoir comme une méthode infaillible auto-suffisante.

Même si je devrais en faire plus souvent.

[B.AF]

Moi entre me dire que j'ai 15000 tests unitaires avec un intitulé clair, une spécification et avoir un debugger, je prends aujourd'hui, pour ce que je fais les tests.

En plus, à force, le debugger rend fainéant et donne de mauvaises habitudes. Travailler sans ça aide aussi à développer sa qualité de code et de relecture.

[Fabllot]

En plus, à force, le debugger rend fainéant et donne de mauvaises habitudes. Travailler sans ça aide aussi à développer sa qualité de code et de relecture.

C'est bête, tu disais des choses censées et là, paf ! dans le panneau...
Comme tu disais si bien quelques posts plus hauts:

Ca me gonfle ce truc de pouces, s'il faut se contenter de dire ce qui plait; autant dire qu'on va en dire des conneries..

Et comme le rappellait TropMDR:

un debuger, c'est "j'ai un bug, je dois trouver d'où il vient exactement, pour le résoudre", alors qu'un test unitaire c'est "j'ai un programme, est ce qu'il a des bugs ?". Donc les deux ne sont pas interchangeable, ils sont complémentaire.

Tu as probablement de la chance de pouvoir faire des tests unitaires, car ce n'est pas le cas pour tout le monde... Dans certains domaines (dont le mien), on peut déjà difficilement tenir les délais demandés, alors les tests unitaires ne peuvent être mis en place (d'ailleurs si il y a une phase de test c'est déjà pas mal)...

Tu diras certes que les tests unitaires c'est du temps de gagner par la suite, et je dirai que tu as sans doute raison. Le plus rapide c'est encore de bien réfléchir à la structure du programme, bien connaitre son langage pour éviter les pièges et le coder sans erreur... Mais là on est utopique !

Bien souvent le client veut voir quelque chose très vite, même de piètre qualité... Il est toujours temps de patcher quelques bugs par la suite.

Cependant, en avance de commentaires à suivre, ce n'est pas parce-que je fais cela, que ça me plait et que je suis d'accord avec, on a bien souvent pas trop le choix. Et ces principes fonctionnent aussi dans mes domaines d'activités. Je conviens bien évidemment que ce n'est pas le cas partout !

[super_bus]

La question que je me pose en voulant lisant est l'intérêt d'un débogueur ?

D'abord, il y a la complexité du langage utilisé. Travailler en assembleur (mais qui le fait encore aujourd'hui) nécessite un débogueur surtout si vous ne faite que de la maintenance (donc vous n'avez rien développez de cette application) et que la logique du programme n'est pas votre logique. Il faut un certain temps pour comprendre ce que fait le programme, et un débogueur vous fait gagner du temps. Et ce, même si vous développez une nouvelle application en assembleur.

Ensuite si vous utilisez un langage évolué comme du C++, l'application ne s'écrit pas en un seul bloc mais se construit pas à pas. Et donc j'espère que vous testez chaque étape dans vos développements. Et si vous avez un bogue alors vous savez que cela concerne les dernières lignes écrites. Un bon COUT (C++) ou PRINT (C) ou encore un DISPLAY (COBOL) est largement suffisant car vous savez où chercher !

Mais si vous avez plusieurs années d'expériences en informatique, un débogueur ne vous plus à rien.

Maintenant la constatation est la suivante :

1) connaissez vous parfaitement le langage que vous utilisez ? hormis l'assembleur qui est un cas particulier, en principe vous n'avez pas besoin d'un débogueur.

2) connaissez-vous une méthodologie de développement ? En principe cela évite un certain nombres de bogues.

3) suivez-vous parfaitement la méthodologie ? Et bien c'est là que l'on rencontre les bogues lorsque l'on veut sortir des sentiers battus.

4) s'il s'agit d'une mise au point (suite à des testes), relisez votre code et corrigez tout ce qui n'est pas aux normes.

Pour ma part, je ne connais aucun débogueur car je développe en suivant une méthodologie et je respecte les normes du langage. De plus, j'évite les programmes monstrueux. Je préfère écrire plusieurs modules géré par un programme chapeau dont sa fonctionnalité est de gérer les appels. Si j'ai un problème alors j'utilise le bon vieux COUT, PRINTF, DISPLAY ... qui est à ma disposition et en général, l'erreur vient d'un non respect de ces normes.

Mais si le problème ne vient pas de votre développement, le débogueur ne fera que constater l'anomalie mais ne vous permettra pas de la résoudre car un débogueur ne vous indique jamais comment corriger cette anomalie.

Et enfin, si vous êtes le développeur de votre application, j'espère que vous suivez une méthodologie de développement et que vous savez ce que vous faite. Si vous êtes logique avec vous même, vous serez logique dans votre développement et un débogueur ne vous sert plus à rien.

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.

Pour illustrer cela, considérez que vous faite de la bicyclette ! Avez-vous encore besoin d'un tricycle ?

[gl]

Maintenant la constatation est la suivante :

1) connaissez vous parfaitement le langage que vous utilisez ? hormis l'assembleur qui est un cas particulier, en principe vous n'avez pas besoin d'un débogueur.

2) connaissez-vous une méthodologie de développement ? En principe cela évite un certain nombres de bogues.

3) suivez-vous parfaitement la méthodologie ? Et bien c'est là que l'on rencontre les bogues lorsque l'on veut sortir des sentiers battus.

4) s'il s'agit d'une mise au point (suite à des testes), relisez votre code et corrigez tout ce qui n'est pas aux normes.

...

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.

Bien entendu, il n'arrive jamais que l'on ait besoin de maintenir un code truffé de problème que l'on n'a pas écrit, que l'on soit obligé de rentrer dans un code écrit par un tiers, etc.

[B.AF]

C'est bête, tu disais des choses censées et là, paf ! dans le panneau...
Comme tu disais si bien quelques posts plus hauts:

Oui le debugger rend fainéant. Combien de fois j'ai entendu des developpeurs me dire 'c'est pas grave je vais le faire en debug'.

C'est pas vraiment l'image du tricycle, c'est plutôt l'image des petites roues. Cela dit, je n'ai jamais dit que le debig est inutile et quand je peux m'en servir et que c'est efficace je m'en sers avec joie. Pour moi, c'est comme le code completion, c'est un atout de l'avoir.

Maintenant, comme tous les outils, son abus et souvent le signe d'un mal bien plus profond.

Typiquement, le cas s'était posé avec .Net sous VS 2008 SP1 :
- Dans le cas 1, le dev travaille en x86
- Dans le cas 2 en x64

Le debugger x64 ne permet pas la modification à chaud, et mécaniquement, ca a changé la façon de développer, parce que le debug devenait plus du contrôle et donc le code brut de fonderie a mis plus de temps à sortir, mais plus robuste en sortie d'usine, et il s'est produit plus de tests unitaires.

De la même façon si tu bosses sur des ponts COM, de la programmation asynchrone, des plateformes de web service avec des technos hétérogénes, même sur du simple MT, le debug n'est pas toujours aussi utile et c'est bien de pouvoir trouver des solutions et des idées qui permettent d'augmenter la productivité.

Typiquement, un bon logger sur un plateforme web service en java permet de tracer toutes les exécutions pendant qu'on développe un client en .Net. Et pour moi, ce sont aussi des méthodes et des outils importants.

De la même façon qu'utiliser des outils comme resharper rendent paresseux sur le nommage ou l'indentation.

Je suis un peu oldschool mais je crois aussi que le meilleur moyen d'apprécier un outil à sa juste valeur et de comprendre ce qu'implique de fonctionner sans.

Donc oui je comprends qu'on puisse perdre l'habitude du recours au debugger, ce qui est dommage, c'est surtout de ne pas s'en servir quand il représente un vrai gain de productivité.

[TropMDR]

1) connaissez vous parfaitement le langage que vous utilisez ? hormis l'assembleur qui est un cas particulier, en principe vous n'avez pas besoin d'un débogueur.

Il n'y a des bugs que dans les programmes écrit en assembleurs ????? Merde alors, je ne pensais pas qu'autant des programmes que j'utilise étaient écrit en assembleur...

3) suivez-vous parfaitement la méthodologie ? Et bien c'est là que l'on rencontre les bogues lorsque l'on veut sortir des sentiers battus.

Effectivement, si on suit parfaitement la "méthodologie" en C, il y a 0% de chance de faire un double free. Ca se saurait...

Pour ma part, je ne connais aucun débogueur car je développe en suivant une méthodologie et je respecte les normes du langage. De plus, j'évite les programmes monstrueux.

Et moi je prouve mes programmes en Coq. J'ai zéro bug. Mathématiquement prouvé. En revanche, je ne viens pas expliquer aux gens qui ont des bugs que ce sont des débiles. Parce que je n'écris pas de serveur web répondant à des milliers de connexion par secondes, on des navigateurs réagissant au clic en moins d'un quart de seconde.

Mais si le problème ne vient pas de votre développement, le débogueur ne fera que constater l'anomalie mais ne vous permettra pas de la résoudre car un débogueur ne vous indique jamais comment corriger cette anomalie.

Son boulot n'est pas de dire comment corriger l'anomalie. Juste de dire *précisément* où est l'anomalie, c'est à dire à quelle ligne dans le code, et dans quel contexte précis...

Et enfin, si vous êtes le développeur de votre application, j'espère que vous suivez une méthodologie de développement et que vous savez ce que vous faite. Si vous êtes logique avec vous même, vous serez logique dans votre développement et un débogueur ne vous sert plus à rien.

Non mais j'ai beau être hyper logique, il m'arrive d'avoir un doigt qui ripe, et un <= length se glisse à la place d'un <= length - 1, ou que sais je.

Un débogueur est valable pour les débutants, pour se former à la compréhension du langage.

Rah, je me suis fait avoir comme un bleu ! En fait, c'était juste un gros troll velu Parce que quand on voit gdb, dire que c'est un "outil pour débutants"...

[super_bus]

Réponse à gl :

Car tu as l'habitude de mettre en exploitation des programmes complétements bogés ! Le débogage d'un programme commence, QUAND TOI tu viens de le modifier et que tu fais des tests. Je suppose que tu n'as jamais entendu parlé de recettes techniques, ni fonctionnelle, ni d'intégration ?

Si un programme a été écrit par un tiers, je ne vois pas en quoi cela pose un problème ? Le seul problème est de comprendre sa logique qui n'est pas la tienne. Et tu as besoin d'un débogueur pour cela ?



Réponse à TropMDR :

a) La mise au point d'un programme écrit en assembleur est plus compliquée car il faut analyser les registres, la mémoire ... faire un vidage de la mémoire du système.

b) Je crois que vous confondez l'écriture d'un programme et sa mise au point. Une telle erreur en C ne nécessite pas un débogueur. L'anomalie détectée lors de l'exécution, vous savez automatiquement la nature de cette erreur. Ensuite c'est à vous de corriger cela dans votre source. A moins que vous ne sachez pas comment développer un programme.

c) Je n'ai pas dit débile mais incompétent. Et ce n'est pas à moi de vous apprendre votre métier alors ne le faire pas à mon égard.

d) Je crois que vous n'avez pas une grande expérience dans la recherche des anomalies. Il arrive qu'une erreur est détectée à un endroit précis du programme mais que la cause est ailleurs. Le débogueur ne vous sera d'aucune utilité pour son identification. Vous constaterez simplement le fait. Après vous devez vous replonger dans le code et faire des tests pour encadrer l'origine de l'erreur. Pour remédier à cela, comme je le dit ci-dessus, il faut bien connaitre le langage que vous utilisez ainsi que la méthodologie de développement. Et ne pas faire une usine à gaz !

e) Pour un "length" au lieu d'un "length -1", ce sont les tests fonctionnelles qui vous dirons la nature du problème. Je ne vois pas à quoi sert dans ce cas un débogueur.

f) Ah OUI ! Alors expliquez moi, gros malin que vous êtes, pourquoi les concepteurs de langage n'utilisent pas les débogueurs ? Puisque c'est le thème de ce thread !

[B.AF]

Ca existe des technos où ce qui est écrit par un tiers n'est pas nécessairement compréhensible : typiquement du perl; d'ailleurs c'est quasiment son modo.

Sur du Java, où il y a beaucoup d'assemblage de librairie, on ne connait pas nécessairement les librairies et il n'est pas toujours possible de les debugger.

Maintenant de toutes façons, c'est un sujet polémique vu que finalement ceux qui n'ont travaillé que sur des langages récents et avec des ide actuels ne peuvent pas vraiment se poser cette question. C'est un peu comme le téléphone : ceux qui sont nés avec le portable ne se posent pas la question du pourquoi le téléphone est devenu portable. Ca ne veut pas pour autant dire qu'ils ont raison.

[bioinfornatics]

Comme pas mal de monde ici j'utilise pas souvent le debugger mais plus le print.
Puis Par habitude je met des bog debug avec des print (oui c'est du D )
comme ça les régions critiques de codes sont printé et je peucx les laissé dans le code. En simplement compilant mon code avec le flag debug j'active les boc

Code :

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

1
2
3
debug{
    Stdout.formatln("value: {}", maVar).nl;
}

je peux même activer des regions de code debug précises car on peut nommer
[code]

Code :

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

1
2
3
debug(AlgorithmXXX){
    Stdout.formatln("value: {}", maVar).nl;
}

et à la compilation on met le flag debug avec le nom ici AlgorithmXXX

Bref au final plus pratique, on a une vision global très très pratique

vive D