Naturalmente, è molto utile utilizzare un framework di registrazione per i messaggi di errore o gli avvertimenti. Ma a volte uso System.out.println () se voglio provare qualcosa di nuovo in poco tempo.
È davvero così brutto usare System.out.println () per qualche test rapido?
Come rivelato nei commenti, la vera domanda che viene posta è: Perché gli strumenti di analisi del codice statico usano flag di System.out.println?
Il motivo è che l'invio di messaggi allo stdout è solitamente inappropriato in un ambiente di produzione. Se stai codificando una libreria, la libreria dovrebbe restituire le informazioni al chiamante, non stampare su stdout. Se stai codificando un'app della GUI, le informazioni dovrebbero essere presentate all'utente, non a dove stdout sta puntando (che potrebbe essere in nessun posto). Se stai codificando un server (o qualcosa che viene eseguito in un contenitore sul lato server) dovresti utilizzare qualsiasi funzione di registrazione fornita dal framework. E così via.
Ma se stai usando println per il debug o lo sviluppo, o stai scrivendo un programma e leggi stdin e scrive su stdout, println va perfettamente bene. Non c'è niente di sbagliato in questo tipo di casi.
Tutto stdout è memorizzato nel buffer, quindi è possibile che il tuo programma si blocca dopo hai chiamato println() , ma prima raggiunge lo schermo.
Detto questo, questo scenario è davvero improbabile. Vai avanti e usalo, ma mantieni la limitazione minore nella parte posteriore della mente.
System.out è solo un% co_de fasciato. Questo è probabilmente simile a qualsiasi framework di registrazione che userete, i framework forniscono semplicemente più funzionalità sotto forma di configurazione e destinazione dell'output del registro
È brutto se stai lavorando su un programma non banale e tu
Ci sono alcuni avvertimenti sull'utilizzo di System.out , anche nel codice di esclusione.
Uno dei problemi principali è che di solito è lento . Ad esempio, se stai cercando di avere un'idea approssimativa della velocità di alcuni codici (nota che i microbenchmark sono difficili ), quindi l'aggiunta di un singolo System.out.println() può davvero rovinare il tuo timing (perché è sincronizzato e spesso attende che l'output effettivo sia visibile all'utente prima di tornare).
Oltre a questo, non mi preoccuperei troppo di questo nel codice usa e getta. Se intendi impegnarlo (sia esso come codice di produzione o come codice di test), allora dovresti sbarazzartene e sostituirlo con una chiamata di registrazione dell'elica (sì, anche nel codice di prova).
Come spesso accade, la risposta è "dipende". Se la tua applicazione ha già un framework di registrazione, allora puoi anche usarlo. Non può essere meno capace di println() , e puoi trarre beneficio da altre funzionalità che fornisce: tracce di stack, contesto extra, formattazione migliore e così via. Vi è anche la netta possibilità che i framework di registrazione offrano un migliore recupero degli errori, garantendo che i tuoi registri vengano scritti correttamente anche in caso di un errore catastrofico.
Quindi la domanda diventa quando aggiungere un sistema di registrazione in primo luogo. Questo è un giudizio: non vuoi aggiungerlo troppo presto, solo per scoprire che non ne hai davvero bisogno. Inoltre, non si desidera aggiungerlo troppo tardi e eseguire una conversione eccessiva del lavoro dalla soluzione ad hoc.
Se scopri che stai facendo un sacco di logging con println() , allora il tuo codebase sta cercando di dirti che sta avendo problemi di crescita. A quel punto, vale la pena investire nella corretta registrazione.
Ho spesso il problema che System.out.print utilizza la codepage "default del sistema", che spesso è UTF-8 sotto Linux, ma alcuni hanno sottotitolato la roba MS in Windows.
Questo può portare a caratteri unicode che sono o non sono stampati correttamente sullo schermo, a seconda di dove viene eseguito il programma.
Preferisco quindi una PrintWriter personalizzata su System.out
Non è affatto male. La nozione potrebbe derivare dal fatto che è molto semplice e non sofisticata come usare un framework di registrazione dedicato nella tua applicazione.
Tuttavia, questo non vuol dire che sia un approccio non valido. L'ho usato molte volte per controllare il flusso delle applicazioni dopo alcuni black magic voodoo hijinks di programmazione.
Il più grande problema con System.out.println occazionale, come vedo, è che si tratta di un "cattivo odore (tm)". Se ti ritrovi a fare ciò, probabilmente potresti migliorare la tua efficacia diventando più a tuo agio usando il tuo debugger preferito.
Anche con un debugger, sai per certo che un breakpoint non scivolerà nel tuo codice di produzione, mentre potrebbe esistere un System.out.println.
Da una nota a margine, se in realtà stai facendo solo un test rapido e persisti a non usare un debugger, penso che System.out.println sia meglio di un framework di logging, dal momento che se accidentalmente lasci un log.debug dichiarazione quando hai finito, è più difficile da sradicare.
Costruire un'intera strategia di testing intorno a echeggiare il contenuto dello stato interno non è la mossa più intelligente, ma per test rapidi e sporchi di codice in fase di sviluppo la stampa dispari qua e là non farà male finché ti ricorderai di rimuoverli !
Il pericolo di dimenticare di rimuoverli è probabilmente il motivo per cui è sconsigliato.
Leggi altre domande sui tag testing code-quality programming-practices java source-code