Pourquoi l'utilisation de System.out.println () est-elle si mauvaise?
Bien sûr, il est très utile d'utiliser un cadre de journalisation pour les messages d'erreur ou les avertissements. Mais parfois j'utilise System.out.println () si je veux essayer quelque chose de nouveau en peu de temps.
Est-ce vraiment si mauvais d'utiliser System.out.println () pour un test rapide?
Comme indiqué dans les commentaires, la vraie question posée est la suivante: pourquoi les outils d'analyse de code statique signalent-ils les utilisations de System.out.println?
La raison en est que l'envoi de messages à stdout est généralement inapproprié dans un environnement de production. Si vous codez une bibliothèque, la bibliothèque doit renvoyer des informations à son appelant, pas imprimer sur stdout. Si vous codez une application graphique, les informations doivent être présentées à l'utilisateur, et non à l'endroit où stdout pointe (ce qui pourrait être nulle part). Si vous codez un serveur (ou quelque chose qui s'exécute dans un conteneur côté serveur), vous devez utiliser la fonction de journalisation fournie par le framework. Et ainsi de suite.
Mais si vous utilisez println pour le débogage ou le développement, ou si vous écrivez un programme et lit stdin et écrit sur stdout, println est parfaitement bien. Il n'y a rien de mal à ce genre de cas.
Tout stdout est mis en mémoire tampon, et il est donc possible que votre programme se bloque après vous avez appelé println(), mais avant il atteint l'écran.
Cela étant dit, ce scénario est vraiment peu probable. Allez-y et utilisez-le, mais gardez juste cette limitation mineure à l'esprit.
System.out n'est qu'un BufferedOutputStream enveloppé. Ceci est probablement similaire à n'importe quel cadre de journalisation que vous utiliserez, les cadres fournissent simplement plus de fonctionnalités sous la forme de configuration et de destination de votre sortie de journal
C'est mauvais si vous travaillez sur un programme non trivial et que vous
- Utilisez System.out comme béquille au lieu de tests unitaires automatisés (JUnit)
- Passez beaucoup de temps à créer et supprimer ou commenter/décommenter des instructions System.out
Il y a quelques mises en garde sur l'utilisation de System.out, Même dans le code jetable.
Un problème majeur est qu'il est généralement lent . Par exemple, si vous essayez d'avoir une idée approximative de la vitesse d'un code (notez que les microbenchmarks sont difficiles ), alors ajouter une seule System.out.println() n'importe où peut vraiment gâcher votre timing (car il se synchronise et attend souvent que la sortie réelle soit visible pour l'utilisateur avant de revenir).
En dehors de cela, je ne m'inquiéterais pas trop à ce sujet dans le code jetable. Si vous avez l'intention de le valider (que ce soit en tant que code de production ou code de test), vous devez vous en débarrasser et le remplacer par un appel de journalisation propper (oui, même dans le code de test) .
Comme c'est souvent le cas, la réponse est "cela dépend". Si votre application dispose déjà d'un cadre de journalisation, vous pouvez également l'utiliser. Il ne peut pas être moins que println(), et vous pouvez bénéficier d'autres fonctionnalités qu'il fournit: traces de pile, contexte supplémentaire, meilleur formatage, etc. Il existe également une possibilité distincte que les cadres de journalisation offrent une meilleure récupération des erreurs, garantissant que vos journaux sont écrits avec succès même en cas de défaillance catastrophique.
La question devient donc quand ajouter un système de journalisation en premier lieu. Ceci est un appel au jugement: vous ne voulez pas l'ajouter trop tôt, seulement pour découvrir que vous n'en avez vraiment pas besoin. Vous ne voulez pas non plus l'ajouter trop tard et effectuer un travail excessif de conversion à partir de votre solution ad hoc.
Si vous découvrez que vous effectuez beaucoup de journalisation avec println(), votre base de code essaie de vous dire qu'elle éprouve des difficultés croissantes. À ce stade, il vaut la peine d'investir dans une journalisation appropriée.
J'ai souvent le problème que System.out.print utilise la page de code "par défaut du système", qui est souvent UTF-8 sous Linux, mais quelques trucs MS misérable sous Windows.
Cela peut conduire à des caractères Unicode qui sont ou ne sont pas correctement imprimés à l'écran, selon l'endroit où le programme s'exécute.
Je préfère donc un PrintWriter personnalisé à System.out
Ce n'est pas mal du tout. La notion peut provenir du fait que c'est très simple et pas aussi sophistiqué que d'utiliser un cadre de journalisation dédié dans votre application.
Cependant, cela ne veut pas dire que c'est une approche invalide. Je l'ai utilisé plusieurs fois pour vérifier le flux d'application après quelques black magic voodoo hijinks de programmation.
Le plus gros problème avec le System.out.println occasionnel, comme je le vois, est que c'est une "mauvaise odeur d'habitude (tm)". Si vous vous trouvez en train de faire cela, alors vous pourriez probablement améliorer votre efficacité en vous sentant plus à l'aise en utilisant votre débogueur préféré.
De plus, avec un débogueur, vous savez avec certitude qu'un point d'arrêt ne se glissera pas dans votre code de production, contrairement à System.out.println.
Soit dit en passant, si vous effectuez simplement un test rapide et persiste à ne pas utiliser de débogueur, je pense que System.out.println est mieux que d'utiliser un cadre de journalisation, car si vous laissez accidentellement une instruction log.debug lorsque vous c'est fait, c'est plus difficile à extirper.
Construire une stratégie de test entière autour de l'écho du contenu de l'état interne n'est pas le plus intelligent, mais pour des tests de code rapides et sales en cours de développement, l'impression étrange ici et là ne fera pas de mal tant que vous vous souvenez de les supprimer!
Le danger d'oublier de les retirer est probablement pourquoi il est déconseillé.