Discussion :

[r2d2abc]

Salut à tous, il m'arrive souvent qd j'intègre du code de faire des sorties console pour vérifier le bon fonctionnement de la méthode/classe/....
Très rapidement, au fur et à mesure du dev/mise au point il existe des sysout partout, des printstack dans tous les catch, des blocs en commentaires, ..le code devient relativement dense .
Qd il est bon j'enlève tout ces lignes de trace (j'en rajoute un autre propre à l'appli) et le code devient nickel, si une extension doit être effectuée ou une amélioration quelconque, il faut repasser tous les tests, donc réimplanter tous les sysout/.etc... Dans d'autres langages il existe des systèmes (macro par ex) qui par une ligne/instruction permettent d'implanter des mécanisme d'introspection/suivi en activant/skippant les traces si une macro est définie ou non.
Comment régler cette problématique, transposer cette technique ou en utiliser une autre ?
Merci de vos réponses.

[Deaf]

Le System.out (ou System.err) est à éviter. En général, sa durée de vie ne doit pas dépasser l'heure...

Il existe quelques exception comme pour un outil en ligne de commande par exemple.

Dans ton cas, tu peux utiliser un logger, comme ça tu n'auras pas à supprimer tes lignes : quand tu n'en auras plus besoin, tu le désactiveras ou tu modifiera son niveau pour ignorer ces messages.

Une autre solution, est la programation par aspect. Elle demande un outillage supplémentaire, mais elle a l'avantage de ne pas toucher à ton code.

[r2d2abc]

Merci de ta réponse Deaf, j'hésitais et tjrs à passer par là (aop) et les loggers sont déjà bien utilisé, mais je suppose qu'il n'y pas de miracles non plus.
...

[adiGuba]

Salut,

et les loggers sont déjà bien utilisé

Si tu les utilises déjà quel est le problème ???

a++

[r2d2abc]

salut, en fait je crois que je cherchais qqchose du style compilation conditonnelle, de moins verbeux, de plus compact et opaque dans sa mise en oeuvre, faire du log4j pour tester la moindre chose ne m'apparaît pas tjrs approprié. C'était une réflexion d'ordre globale qd au dev en mode r&d/test/intégration. Sans conteste java a des qualités indéniables qd il s'agit de coder rapidement et de manière sûre, mais je réfléchissais à quelque chose du style cadre de dev en mode final ou intermédiaire ou tout un ensemble de lignes pourraient être préfixée par des macro commandes qui seraient opacifiées par l'éditeur (style eclipse ou ..) au moment de l'intégration finale pour ne faire apparaître que le code final sans toutes les lignes intermédiaires non exécutées en prod par des tests de booleens qui signifient que l'on ne veut plus de traces et qui bouffent des appels/stacks/.. . C'était plus un post de type réflexion qd à une nouvelle manière de s'y prendre que je m'étais un peu fixée pour cette année.
PS: très bien ton article / références

[Deaf]

D'après ce que je comprends de ton besoin, l'AOP semble le plus adapté. Ton code de test ne polluera pas ton code tout en s'insérant où tu en as besoin.

[adiGuba]

Code :

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

1
2
3
4
5
6
7
8
public static final boolean DEBUG = true;
 
// ...
 
 
if (DEBUG) {
    // Code exécuté en DEBUG
}

Ensuite il suffit de modifier la valeur de la constante et de tout recompiler.

Si tu utilises bien une constante alors la totalité du bloc if() sera supprimé dès la compilation et ne sera donc même pas présente dans le fichier *.class.

Si tu utilises une variable, le code est présent dans le .class mais pourrait être supprimé dynamiquement à l'exécution par le compilateur JIT.


a++